Hey. Just by now,... two additional cases of security problems crossed my mind. Though not related to our package signing, they originate to some extent in the same problem as everything that was discussed in this thread before: 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 maintainers. 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 enough). 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. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
