-------- Original Message --------
Subject: Re: [Pkg-nagios-devel] Bug#547092: Bug#547092:
nagios-nrpe-server: Insecure 'SSL' option, key identical for all debian
systems
From: Christoph Anton Mitterer <cales...@scientia.net>
To: Michael Friedrich <michael.friedr...@univie.ac.at>
Date: 2012-02-20 15:31
On Mon, 2012-02-20 at 14:05 +0100, Michael Friedrich wrote:
https://git.icinga.org/?p=icinga-nrpe.git;a=commit;h=025334c19f252f43c4ae8209ff1eec889908478b
https://git.icinga.org/?p=icinga-nrpe.git;a=blobdiff;f=src/nrpe.c;h=1618be253465e3201ca0c988e176727f77abf8fa;hp=f5859b7a0c4c0aea7246a75fdf0d4c712106c68a;hb=025334c19f252f43c4ae8209ff1eec889908478b;hpb=b3eacf64ff33198c300f8ae72c77eedc91095093
Well but IMHO this rather solve the whole problem, just breaking with
the old code, which was useless anyway.
<dev hat on>
the code was NOT useless. stop blaming the devs for that initial
implementation. do better than that - actually make it better.
<dev hat off>
The other Nagios NRPEs (that could be used on remote host sides) which
still use the fake SSL?
that code is not (yet) compatible. feel free to provide upstream patches
which solve that compatibility breakage problem.
I'm not sure whether there should be any desire to make anything
compatible to the old way.
<users hat on>
why do i have to upgrade my nsclient++ server which only supports the
old nrpe protocol? oh snap, nsclient++ dev refuses to implement the new
nrpe protocol with ssl certs. fuck, i can't upgrade to the new version,
but i really really want to use e.g. ipv6 layer
<users hat off>
same goes for any other addon / plugin making use of the nrpe protocol.
break the protocol, release a new version, depend on all other devs
wanting or willing to implement a new protocol version. hooray. got a
solution for that problem or never thought about that why compatibility
affects more than nrpe client and server communication?
When using SSL, the certificate approach seems best to me. But I'm not
sure if this contradicts one of the main goals of NRPE (performance).
is this just a wild guess, or on what tests are you building this thesis on?
have you ever actually tried that patch you are referring to, like you
posted the url to?
the packaged version remains "rather useless" as the generated dh key
happens on configure. so installing the built binary package isn't that
security aware, though the source install does generate a new dh key
everytime you call configure. by that means, upstream probably does not
see the opportunity to include such patches/changes with high priority.
Well but in the real world, no one is going to compile them manually.
LOL. probably you are working on the wrong support channels (if so). i
know a lot users, who resist my advisories to use packages instead.
And still, you'd have one shared secret for the whole cluster.
depending on the install method. you cannot guess on internal deployment
mechanisms, that's merely different for each and everyone.
and with upstream, i do mean the official nagios nrpe project. the
icinga one is just an unofficial fork
What do you mean? That the Icignga NRPE is not officially distributed by
Icinga itself?
not yet. that's why you can see the git, the dev tracker, and a release
target. but not a date nor a possible roadmap itsself.
That would be bad of course :-(
sure. but if there are no maintainers who like to invest some of their
time, it will be like that. i'll be willing to share my knowledge on
what i've already done with it (as well as the others who provided
patches), but then it's up to the community for now.everyone's invited
to contribute in productive way...
if you got any better (aka a valuable patch), provide those please
instead of just nagging the package maintainers for things people know
for at least 5 years already. do something about it.
Well it seems there are patches, which solves the issue already in a
secure way.
that's still only one way to go as those patches suggest. there might be
other ways as well (see the infamous "dont_blame_nrpe" feature. you will
be even more shocked, when you analyse that in deep (and find possibly
bugs on command parsing and injections *cough*).
For the reasons I've pointed out above, I believe that the
one-set-of-DH-params per cluster is broken by design.
So while I guess that it should be fairly easy to make a patch that
simply can both (e.g. one --ssl-dh and one -ssl-certificates) option, I
don't see much reason of wasting effort into it.
see above, especially on the protocol note.
mentioned bug with nrpe and ssl is such a thing and can truly understand
that alex does not want to patch his packages when upstream source
compiled builds behave differently.
Well it really seems that at least the nagios upstream will never change
this..
you in person have never asked ... so far the least i haven't seen a
question of yours on nagios-devel lists or the nrpe bug tracker.
you should probably start a discussion on nagios-devel mailinglists,
where the developers of nrpe read and write. that discussion must be
moved upstream, and not into the package space imho.
Yeah you're right,... I've just commented here, as I thought it
shouldn't be much of an effort to just integrate the patch in Debians
nagios nrpe...
as mentioned previously, behavior changing patches will make packagers
life hard, even harder than an actual fork keeping updated. and yes,
integrating such a patch will most likely be a "fork" of the upstream
releases.
With respect to upstream, I personally will rather trying to contribute
to icinga (and their nrpe) if this is still necessary.
I mean as you pointed out there really is a reason why we have forks,
I'd be happy if the original nagios just dies and all folks move to the
community supported Icinga.
if you reduce the discussion level a bit (the current one is a bit
annoying telling things we already know), and just focus on the problem
and code, i'd love to see some input on the dev tracker. but to be fair,
you should try it at least once on nagios-devel mailinglists, if it's
really /dev/null or just a flamewar.
kind regards,
michael
Cheers,
Chris.
--
DI (FH) Michael Friedrich
Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria
email: michael.friedr...@univie.ac.at
phone: +43 1 4277 14359
mobile: +43 664 60277 14359
fax: +43 1 4277 14338
web: http://www.univie.ac.at/zid
http://www.aco.net
Lead Icinga Core Developer
http://www.icinga.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
