Re: Resurrecting the Securing Debian Manual

--000000000000d72f5606373eb617
Content-Type: text/plain; charset="UTF-8"

On Tue, 10 Jun 2025 at 22:57, Noah Meyerhans <[email protected]> wrote:

> 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

--000000000000d72f5606373eb617
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div><br></div></div><div class=3D"gmail_=
quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, =
10 Jun 2025 at 22:57, Noah Meyerhans &lt;<a href=3D"mailto:[email protected]=
">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">On Tue, Jun 10, 2025 at 09:57:43PM +0200, Javier Fernande=
z-Sanguino wrote:<br>
&gt;=C2=A0 =C2=A0 Moving the manual to a Wiki could be an option but I woul=
d rather first<br>
&gt;=C2=A0 =C2=A0 have an updated version/content using the current package=
/toolset and then<br>
&gt;=C2=A0 =C2=A0 consider moving it to a wiki.<br>
<br>
The current format is arcane and presents a barrier to contributors.<br>
I&#39;m not sure that working within the existing structure (either markup<=
br>
or content) is worthwhile at this point.<br></blockquote><div><br></div><di=
v>I&#39;m not fully convinced that the current format is a barrier to contr=
ibutors as the Debian website uses WML and this has not hindered contributi=
ons. When I&#39;ve received snippets of text (even if unformatted form) I h=
ave gladly included them in the manual. The XML files available in Sala (<a=
 href=3D"https://salsa.debian.org/ddp-team/securing-debian-manual/-/tree/ma=
ster/en-US?ref_type=3Dheads">https://salsa.debian.org/ddp-team/securing-deb=
ian-manual/-/tree/master/en-US?ref_type=3Dheads</a>) can be forked/edited q=
uickly by anybody who has just a basic notion of HTML.=C2=A0 However, the B=
TS and merge requests in the last=C2=A010 years shows that the number of pe=
ople willing to put the work and actually=C2=A0write / contribute=C2=A0is l=
ow.</div><div><br></div><div>I personally also see some advantages to the c=
urrent format (including nice printable versions as well as easy translatio=
ns via PO files) which would be lost if the content is moved to a Wiki form=
at.</div><div><br></div><div>In any case, I would suggest that the best app=
roach to improve the manual would be to first update the existing content i=
n 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&#39;s Wiki.=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&g=
t;=C2=A0 =C2=A0 Alternatively, somebody could start writing in the wiki dif=
ferent sections<br>
&gt;=C2=A0 =C2=A0 related to hardening specific services and, once mature/f=
inished, move it<br>
&gt;=C2=A0 =C2=A0 to the manual.<br>
<br>
Yeah, this may be reasonable.=C2=A0 Holger&#39;s example of the DebianEdu d=
ocs<br>
might be a good one to follow.<br></blockquote><div><br></div><div>I&#39;m =
not aware of what was done in DebianEdu (any ponter&#39;s), but I&#39;m ope=
n to trying alternative approaches.</div><div><br></div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">&gt;=C2=A0 =C2=A0 Personally =
I think that the manual :<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 - Should not cover in details the principles you mention.=
 There is enough<br>
&gt;=C2=A0 =C2=A0 literature out there that it does not make sense to descr=
ibe what other<br>
&gt;=C2=A0 =C2=A0 sources (books / sites) provide better info on (it is man=
ual, not a book!)<br>
<br>
I understand your point.=C2=A0 However, as Schneier and others have observe=
d,<br>
security is a process, not a product (and not a checklist).=C2=A0 In order =
to<br>
adapt to changes with security implications, an admin will need to<br>
understant topics like threat modeling in order to react react<br>
appropriately.=C2=A0 We don&#39;t want to provide a set of receipes/checkli=
sts<br>
and leave the reader with a sense that they&#39;re done when they&#39;ve<br=
>
completed them.=C2=A0 I would expect to provide basic content on these<br>
topics, but to link to external resources for further reading.=C2=A0 So I<b=
r>
think we probably agree; the question will be how to figure out how much<br=
>
detail to include, and when to refer out to some other document.<br></block=
quote><div><br></div><div>I&#39;m not opposed to having a section in chapte=
r 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.</div><div><br></div><div>Actually, I think that this discussion =
on the potential approaches / rewrite and potential distribution of section=
s / workload could be well suited to be documented in a Wiki :)</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt;=C2=A0 =C2=A0 - Should maybe focus only on specific use cases (eg setti=
ng up a server)<br>
&gt;=C2=A0 =C2=A0 rather than trying to cover all potential use cases (eg d=
esktop) unless<br>
&gt;=C2=A0 =C2=A0 there are enough &quot;hands&quot; working on it<br>
<br>
Broadly speaking, I&#39;d say that the two most common use cases can be<br>
classified as either &quot;a system that&#39;s always online and offers net=
work<br>
services&quot; and &quot;a system that runs a web browser and other interac=
tive<br>
applications&quot;, and we should be able to cover those.=C2=A0 We can get =
more<br>
granular or broaden the scope later, as needed.<br></blockquote><div><br></=
div><div>Agreed. Although the current manual is more focused on the first u=
se case in my opinion. It would require a mejor rewrite to fit multiple use=
 cases.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">
&gt;=C2=A0 =C2=A0 Those thoughts aside I would be glad to help in pushing p=
atches / new<br>
&gt;=C2=A0 =C2=A0 versions of the manual to the archive if people start act=
ively<br>
&gt;=C2=A0 =C2=A0 contributing to it.<br>
<br>
...this is exactly what I mean by centrally maintained. :)=C2=A0 The wiki<b=
r>
eliminates the need for merge requests, approvers, etc.<br></blockquote><di=
v><br></div><div>I was referring to the current status quo in which there i=
s one package and a common repository (in salsa). If somebody wants to impr=
ove it *now* and help fix the issues raised in the BTS or add new content t=
his would be the way to go about it.</div><div><br></div><div>Best regards<=
/div><div><br></div><div>Javier</div><div><br></div><div><br></div></div></=
div>

--000000000000d72f5606373eb617--