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.
I'm not fully convinced that the current format is a barrier to contributors as the Debian website uses WML and this has not hindered contributions. When I've received snippets of text (even if unformatted form) I have gladly included them in the manual. The XML files available in Sala (
https://salsa.debian.org/ddp-team/securing-debian-manual/-/tree/master/en-US?ref_type=heads) can be forked/edited quickly by anybody who has just a basic notion of HTML. However, the BTS and merge requests in the last 10 years shows that the number of people willing to put the work and actually write / contribute is low.
I personally also see some advantages to the current format (including nice printable versions as well as easy translations via PO files) which would be lost if the content is moved to a Wiki format.
In any case, I would suggest that the best approach to improve the manual would be to first update the existing content in its current format, get it to a good enough shape that it can be shipped back into Debian proper and *then* consider moving it to Debian's Wiki.
> 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.
I'm not aware of what was done in DebianEdu (any ponter's), but I'm open to trying alternative approaches.
> 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.
I'm not opposed to having a section in chapter 2 (Before you begin) giving guidance to administrators on how to approach the problem. As you said, providing basic guidance and pointing to proper resources.
Actually, I think that this discussion on the potential approaches / rewrite and potential distribution of sections / workload could be well suited to be documented in a Wiki :)
> - 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.
Agreed. Although the current manual is more focused on the first use case in my opinion. It would require a mejor rewrite to fit multiple use cases.
> 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.
I was referring to the current status quo in which there is one package and a common repository (in salsa). If somebody wants to improve it *now* and help fix the issues raised in the BTS or add new content this would be the way to go about it.
Best regards
Javier