Re: Resurrecting the Securing Debian Manual
"Dave P." <[email protected]> Wed, 11 Jun 2025 10:43:37 -0400
| Newsgroups | gmane.linux.debian.devel.security,gmane.linux.debian.devel.documentation |
|---|---|
| Message-ID | <CAFnCXaruZPgR9c2f_=H+fJX8yhTU=4udZm1rfrQ=HrOmk_eGaA@mail.gmail.com> |
--00000000000063802806374cd728 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is some good discussion here. I have some comments for those interested: First, many thanks to Javier for building the *Securing Debian Manual*. That was a massive undertaking, and it is well-written and organized. I used it frequently between 2015 and 2017, and it helped me better secure some Dell R-series servers running Debian. It was invaluable. I haven't used it since 2020 or so, but it was a great help to me in the past. Javier *is* the writer and the maintainer, and has put a lot of work into the manual and the repository at salsa.debian.org over the past decade. When some people see the 2012 copyright notice at the beginning of the manual, they might think it is outdated/abandoned. Based on Salsa, and the response from Javier, it obviously is not abandoned. However, *some* of the content is outdated. A quick search will prove this to be true. For example, 4.11.2 Password security in PAM discusses SHA-512 (and Debian Squeeze). Personally, I don't mind editing within a git-based repository, be it XML or whatever. (And now that I see the omission of yescrypt, I'll commit to 4.11.2.) However, in my experience, people are more likely to contribute in WYSIWYG-based editors than in Git-based ones. It is most definitely easier to edit that way. That said, it is possible to create a dedicated manual section in a Wiki-based site. However, I could imagine some structural/search difficulties. Also, reformatting the entire manual (and the entire process in general) could end up being more than a person bargains for. Anyone who has administered a Wiki in the past can attest to this. Regardless of the updating method, I think the lack of updates in the manual is part of a trend. In my opinion, the entire Debian Wiki (and much of the community - myself included) is guilty of this; especially regarding Debian security. Simply compare the Debian Wiki to the Arch Wiki and you will see my point. So, I agree that editing in a Wiki-based format is easier; however, it doesn't necessarily mean people will do it! Realizing all this, I resolve to commit/edit more. =F0=9F=98=80 Ultimately, Javier is the writer and maintainer of this manual. It is GPL, which of course means that anyone could copy/modify/re-create/etc... *However, a word of caution: updating/recreating a manual of this proportion is a big proposition. Trust me on this - I know! * For now, I *suggest* the following: - Get as many people on board as possible and commit to the *current* manual - but only important, Debian-related, security topics. - Build a nice list of security items that are specifically Debian-centric. For example, the aforementioned yescrypt, nftables in Debian, sshd_config in Debian, etc... (many of these have been listed already in the thread). Divvy those topics up amongst those who wish to participate. This can help to organize the process. - Consider some sort of search tool for the current manual. That is sorely missing. - Create a test, dedicated manual section in the Debian Wiki (or any test Wiki), and convert a portion of the XML files into the Wiki - just to see what we would be up against. =F0=9F=98=89 If, at the planning stage, it all appears to be a bit too much, then I think the community should simply consider building/updating specific Debian-centric, security-related topics within the main Debian Wiki. As mentioned, this is a sore spot in the Wiki and should probably be addressed regardless. As I mentioned, I'm willing to invest some time into this, in whatever way Javier and the community decide to proceed. I think Debian and the Securing Debian Manual are worthwhile efforts. I've worked with boatloads of documentation in the past, and would love to help. And thanks for reading my super-long email! Dave On Tue, Jun 10, 2025 at 5:52=E2=80=AFPM Javier Fernandez-Sanguino <jfs@debi= an.org> wrote: > > 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 wrot= e: >> > 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=3Dheads) > 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 tha= t > 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) givin= g > 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 / n= ew >> > 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 b= e > the way to go about it. > > Best regards > > Javier > > > --00000000000063802806374cd728 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:tahoma,sans-serif;font-size:small">There is some good discussion h= ere. I have some comments for those interested:</div><div class=3D"gmail_de= fault" style=3D"font-family:tahoma,sans-serif;font-size:small"><br></div><d= iv class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-size= :small">First, many thanks to Javier for building the <i>Securing Debian Ma= nual</i>. That was a massive undertaking, and it is well-written and organi= zed. I used it frequently between 2015 and 2017, and it helped me better se= cure some Dell R-series servers running Debian. It was invaluable. I haven&= #39;t used it since 2020 or so, but it was a great help to me in the past.<= /div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;fo= nt-size:small"><br></div><div class=3D"gmail_default" style=3D"font-family:= tahoma,sans-serif;font-size:small">Javier <i>is</i> the writer and the main= tainer, and has put a lot of work into the manual and the repository at <a = href=3D"http://salsa.debian.org">salsa.debian.org</a> over the past decade.= <br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-se= rif;font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-f= amily:tahoma,sans-serif;font-size:small">When some people see the 2012 copy= right notice at the beginning of the manual, they might think it is outdate= d/abandoned.=C2=A0Based on Salsa, and the response from Javier, it obviousl= y is not abandoned. However, <i>some</i> of the content is outdated. A quic= k search=C2=A0will prove this to be true. For example, 4.11.2 Password secu= rity in PAM discusses SHA-512 (and Debian Squeeze). <br></div><div class=3D= "gmail_default" style=3D"font-family:tahoma,sans-serif;font-size:small"><br= ></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;= font-size:small">Personally, I don't mind editing within a git-based re= pository, be it XML or whatever. (And now that I see the omission of yescry= pt, I'll commit to 4.11.2.) <br></div><div class=3D"gmail_default" styl= e=3D"font-family:tahoma,sans-serif;font-size:small">However, in my experien= ce, people are more likely to contribute in WYSIWYG-based editors than in G= it-based ones. It is most definitely easier to edit that way.<br></div><div= class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-size:s= mall"><br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sa= ns-serif;font-size:small">That said, it is possible to create a dedicated m= anual section in a Wiki-based site. However, I could imagine some structura= l/search difficulties. Also, reformatting the entire manual (and the entire= process in general) could end up being more than a person bargains for. An= yone who has administered a Wiki in the past can attest to this. <br></div>= <div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-si= ze:small"><br></div><div class=3D"gmail_default" style=3D"font-family:tahom= a,sans-serif;font-size:small">Regardless of the updating method, I think th= e lack of updates in the manual is=20 part of a trend. In my opinion, the entire Debian Wiki (and much of the com= munity - myself included) is guilty of this; especially regarding Debian se= curity. Simply compare the Debian Wiki to the Arch Wiki and you will see my= point. <br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,= sans-serif;font-size:small">So, I agree that editing in a Wiki-based format= is easier; however, it doesn't necessarily mean people will do it!=C2= =A0</div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-seri= f;font-size:small">Realizing all this, I resolve to commit/edit more. =F0= =9F=98=80</div><div class=3D"gmail_default" style=3D"font-family:tahoma,san= s-serif;font-size:small"><br></div><div class=3D"gmail_default" style=3D"fo= nt-family:tahoma,sans-serif;font-size:small">Ultimately, Javier is the writ= er and maintainer of this manual. It is GPL, which of course means that any= one could copy/modify/re-create/etc... <br><i><b>However, a word of caution= : updating/recreating a manual of this proportion is a big proposition. Tru= st me on this - I know! </b></i><br></div><div class=3D"gmail_default" styl= e=3D"font-family:tahoma,sans-serif;font-size:small"><br>For now, I <i>sugge= st</i> the following:</div><div class=3D"gmail_default" style=3D"font-famil= y:tahoma,sans-serif;font-size:small">- Get as many people on board as possi= ble and commit to the <i>current</i> manual - but only important, Debian-re= lated, security topics. <br></div><div class=3D"gmail_default" style=3D"fon= t-family:tahoma,sans-serif;font-size:small">- Build a nice list of security= items that are specifically Debian-centric. For example, the aforementione= d yescrypt, nftables in Debian, sshd_config in Debian, etc... (many of thes= e have been listed already in the thread). Divvy those topics up amongst th= ose who wish to participate. This can help to organize the process.<br></di= v><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-= size:small">- Consider some sort of search tool for the current manual. Tha= t is sorely missing.<br></div><div class=3D"gmail_default" style=3D"font-fa= mily:tahoma,sans-serif;font-size:small">- Create a test, dedicated manual s= ection in the Debian Wiki (or any test Wiki), and convert a portion of the = XML files into the Wiki - just to see what we would be up against.=C2=A0=F0= =9F=98=89 </div><div class=3D"gmail_default" style=3D"font-family:tahoma,sa= ns-serif;font-size:small"><br></div><div class=3D"gmail_default" style=3D"f= ont-family:tahoma,sans-serif;font-size:small">If, at the planning stage, it= all appears to be a bit too much, then I think the community should simply= consider building/updating specific Debian-centric, security-related topic= s within the main Debian Wiki. As mentioned, this is a sore spot in the Wik= i and should probably be addressed regardless. <br></div><div class=3D"gmai= l_default" style=3D"font-family:tahoma,sans-serif;font-size:small"><br></di= v><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-= size:small">As I mentioned, I'm willing to invest some time into this, = in whatever way Javier and the community decide to proceed.=C2=A0I think De= bian and the Securing Debian Manual are worthwhile efforts. I've worked= with boatloads of documentation in the past, and would love to help. <br><= /div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;fo= nt-size:small"><br></div><div class=3D"gmail_default" style=3D"font-family:= tahoma,sans-serif;font-size:small">And thanks for reading my super-long ema= il!<br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-= serif;font-size:small"><br></div><div class=3D"gmail_default" style=3D"font= -family:tahoma,sans-serif;font-size:small">Dave</div><div class=3D"gmail_de= fault" style=3D"font-family:tahoma,sans-serif;font-size:small"><br></div></= div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" c= lass=3D"gmail_attr">On Tue, Jun 10, 2025 at 5:52=E2=80=AFPM Javier Fernande= z-Sanguino <<a href=3D"mailto:[email protected]">[email protected]</a>> wro= te:<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"><div dir=3D"= ltr"><div dir=3D"ltr"><div><br></div></div><div class=3D"gmail_quote"><div = dir=3D"ltr" class=3D"gmail_attr">On Tue, 10 Jun 2025 at 22:57, Noah Meyerha= ns <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= rg</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi= n: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 Fernandez-Sanguino wrote= :<br> >=C2=A0 =C2=A0 Moving the manual to a Wiki could be an option but I woul= d rather first<br> >=C2=A0 =C2=A0 have an updated version/content using the current package= /toolset and then<br> >=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'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'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'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" target=3D"_blank">https://salsa.debian.org/ddp= -team/securing-debian-manual/-/tree/master/en-US?ref_type=3Dheads</a>) can = be forked/edited quickly by anybody who has just a basic notion of HTML.=C2= =A0 However, the BTS and merge requests in the last=C2=A010 years shows tha= t the number of people willing to put the work and actually=C2=A0write / co= ntribute=C2=A0is low.</div><div><br></div><div>I personally also see some a= dvantages to the current format (including nice printable versions as well = as easy translations via PO files) which would be lost if the content is mo= ved to a Wiki format.</div><div><br></div><div>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.</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);pa= dding-left:1ex">>=C2=A0 =C2=A0 Alternatively, somebody could start writi= ng in the wiki different sections<br> >=C2=A0 =C2=A0 related to hardening specific services and, once mature/f= inished, move it<br> >=C2=A0 =C2=A0 to the manual.<br> <br> Yeah, this may be reasonable.=C2=A0 Holger's example of the DebianEdu d= ocs<br> might be a good one to follow.<br></blockquote><div><br></div><div>I'm = not aware of what was done in DebianEdu (any ponter's), but I'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">>=C2=A0 =C2=A0 Personally = I think that the manual :<br> > <br> >=C2=A0 =C2=A0 - Should not cover in details the principles you mention.= There is enough<br> >=C2=A0 =C2=A0 literature out there that it does not make sense to descr= ibe what other<br> >=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't want to provide a set of receipes/checkli= sts<br> and leave the reader with a sense that they're done when they'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'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> >=C2=A0 =C2=A0 - Should maybe focus only on specific use cases (eg setti= ng up a server)<br> >=C2=A0 =C2=A0 rather than trying to cover all potential use cases (eg d= esktop) unless<br> >=C2=A0 =C2=A0 there are enough "hands" working on it<br> <br> Broadly speaking, I'd say that the two most common use cases can be<br> classified as either "a system that's always online and offers net= work<br> services" and "a system that runs a web browser and other interac= tive<br> applications", 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"> >=C2=A0 =C2=A0 Those thoughts aside I would be glad to help in pushing p= atches / new<br> >=C2=A0 =C2=A0 versions of the manual to the archive if people start act= ively<br> >=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> </blockquote></div></div> --00000000000063802806374cd728--