Re: Resurrecting the Securing Debian Manual
On Tue, Jun 10, 2025 at 09:57:43PM +0200, Javier Fernandez-Sanguino wrote:
> Moving the manual to a Wiki could be an option but I would rather first
> have an updated version/content using the current package/toolset and then
> consider moving it to a wiki.
The current format is arcane and presents a barrier to contributors.
I'm not sure that working within the existing structure (either markup
or content) is worthwhile at this point.
> The manual is not "centrally maintained" as it is available in Salsa for
> anyone to contribute bits and pieces as they see fit.
Well..
> Alternatively, somebody could start writing in the wiki different sections
> related to hardening specific services and, once mature/finished, move it
> to the manual.
Yeah, this may be reasonable. Holger's example of the DebianEdu docs
might be a good one to follow.
> Personally I think that the manual :
>
> - Should not cover in details the principles you mention. There is enough
> literature out there that it does not make sense to describe what other
> sources (books / sites) provide better info on (it is manual, not a book!)
I understand your point. However, as Schneier and others have observed,
security is a process, not a product (and not a checklist). In order to
adapt to changes with security implications, an admin will need to
understant topics like threat modeling in order to react react
appropriately. We don't want to provide a set of receipes/checklists
and leave the reader with a sense that they're done when they've
completed them. I would expect to provide basic content on these
topics, but to link to external resources for further reading. So I
think we probably agree; the question will be how to figure out how much
detail to include, and when to refer out to some other document.
> - Should maybe focus only on specific use cases (eg setting up a server)
> rather than trying to cover all potential use cases (eg desktop) unless
> there are enough "hands" working on it
Broadly speaking, I'd say that the two most common use cases can be
classified as either "a system that's always online and offers network
services" and "a system that runs a web browser and other interactive
applications", and we should be able to cover those. We can get more
granular or broaden the scope later, as needed.
> Those thoughts aside I would be glad to help in pushing patches / new
> versions of the manual to the archive if people start actively
> contributing to it.
...this is exactly what I mean by centrally maintained. :) The wiki
eliminates the need for merge requests, approvers, etc.
noah
Reply to: