Just my 2 cents (without any hat on): TLS integration in NRPE was broken from the beginning and more or less by design.
The "real" and only security feature is to configure a appropriate allowed_hosts list, which might be enough security for internal networks in respect of TCP sessions. Question is: Do we really want to remove NRPE from testing because of it promising a incomplete feature? It should be pointed out that the TLS feature is broken, but still allowing users to use NRPE. Because the problem is: we (Debian) might not be able to change it - but I personally don't want users to use some self built stuff. 2013/2/7 Matt Taggart <tagg...@debian.org>: > As pointed out in a previous message to the bug, #547092 > "nagios-nrpe-server: Insecure 'SSL' option, key identical for all > debian systems" is severity grave due to the security problem it > introduces in the service (but not critical since the problem is > limited to the nrpe service). I have adjusted it. > > This bug hasn't had any activity for almost a year and was mostly > shouting before that. This package shouldn't be in testing/stable > until this is fixed lest others (as I did) spend a bunch of effort > implementing lots of nrpe based checks before realizing they just > opened a security hole on all their systems... > > If this can't be solved, maybe we could recommend better > alternatives? -- Markus Frosch mar...@lazyfrosch.de http://www.lazyfrosch.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
