[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: leaks in our only-signed-software fortress


Just by now,... two additional cases of security problems crossed my
Though not related to our package signing, they originate to some extent
in the same problem as everything that was discussed in this thread
Insufficient "feeling" for security [by maintainers].

1) Silent modification of defaults.
IMHO, it's perfectly well for a maintainer, to modify the default
_configuration_ of and even to "lower" security by that (to the later:
if there is really good reason for it).
The admin installing the package shall be expected to go through the
configuration and understand it. If he doesn't it's his fault not the

But I've already seen several cases, where maintainers choose to
directly modify (patch) the defaults in the program code.
Sometimes this was for good reasons, sometimes I could not follow it (as
in my mind, a simple change of the default config would have been

Nevertheless, in such a case it is utmost important that these
modifications are documented.
And not just in the quilt patch header.
This should really go into several places:
- any --help output of the program itself must be updated, too.
- manpages/documentation should be added with information (in the
respective sections) that Debian deviates from the upstream default
value (and how).
- There should be one central point, where all those modifications are
_clearly_ (that is not hidden between words of text) documented
(probably README.Debian).

2) Well I really feel bad now, having to point my finger at the Nagios
Maintainers as they really do a good job, but this just shocked me:
Bug #660585.

Well as I describe in the bug, it is practically (at the moment) of no
relevance as SSL in Nagios' NRPE is broken.
The problem here is IMHO rather the attitude behind.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: