REvised links at end of this post. On Sun, Jan 31, 2021 at 03:16:53AM +0000, Ken Moffat via blfs-dev wrote: > On Sun, Jan 31, 2021 at 09:55:10AM +0800, Kevin Buckley via blfs-dev wrote: > > On Fri, 29 Jan 2021 at 11:37, Ken Moffat via blfs-dev > > <blfs-dev@lists.linuxfromscratch.org> wrote: > > > > > > > Stiil of the opinion, FWIW, that, as thse entries are already on a > > "Security Advisories" page, the entries should start with the package > > name rather than having the package name halfway down a sentence > > in which we re-affirm that there are "Vulnerabilities", as if being on a > > "Security Advisories" page, wasn't enough. > > > > For me then, alphabetically, by package name, > > [...] > > > > I'd also like to suggest that the newest vulnerability goes at the top of > > the list for any given package, on the assumption that the latest version > > of any given package would typically fix all earlier vulnerabilities. > > > > Just my thr'pen'th though, > > Kevin > Hi Kevin, > [...] > > I suppose that linking to a separate page (with the detail) which is > only in numeric sequence could solve that, i.e. have the advisory > links for a book version grouped in newest-first within-alphabetic > order with links to a separate page, and each of those pointing to > the consolidated (ongoing) list where the details are held. > > So, for firefox the newest advisory would be for 78.7.0, with 78.6.1 > before that, etc. For JS78 the newest would be 78.7.0 with 78.5.0 > before that. > > That approach sounds plausible. I might play with it. > Done something like that, links at the end.
> I'm also wondering if it would be better to label advisories within > the book version. The current advisories are for BLFS-10.0 although > they may also apply to earleir books. I'm thinking that what is > currently 200901 would become 10.0 001 (hopefully we don't get more > than 999 in six months). Hmm, maybe if the complete list, with > details, is on a separate page that could include the date (at the > moment I've done September according to when the package was > updated, although for some items it might not have been obvious > until later that an advisory was needed. If this goes live, that > problem should disappera. > Done the that too, and also trialled making this for LFS as well as BLFS. At the moment, for LFS we need to look at each individual LFS ticket to see if it fixed any vulnerabilities. We have no items in Stable LFS Errata because nothing in the instructions has been deemed to merrit an erratum. Current links: 1. The original version is for the moment still at http://www.linuxfromscratch.org/blfs/advisories/ i.e. it is the index.html file. I'd like to remove the content and change it to a 'menu' for the versioned advisories (currently only 10.0, later add 10.1 etc) and for the consolidated list. 2. The revised details for 10.0 are at http://www.linuxfromscratch.org/blfs/advisories/10.0.html with short summaries of the issue / what to do, and links to fuller details on the consolidated page. I'm using the book's stylesheets and small headers, to my eyes there is too much space between the numbered header and the text. Not sure if that can be fixed. I've also tended to write "Update to ..." instead of "To fix this, update to ...". For me the shorter form is preferable for this page, but perhaps people whose first language is not English would prefer the longer version ? 3. The consolidated list (in advisory number order, descending) is at http://www.linuxfromscratch.org/blfs/advisories/consolidated.html and I've put the example LFS advisory at the top. I'd very much like to include the LFS items to bring it all together, that might mean renumbering some of what I've already done if there was anything in September. For the moment there are 3 paragraphs per item: · Effective date (usually when the book was updated, for the future it might be a few days later if the security aspect is not obvious when the book gets updated). Might be followed by a Revised date, as in Thunderbird-78.3.0 (vulnerability) but use Thunderbird-78.3.1 (doesn't crash like 78.3.0). · Summary, usually with external link(s). · Instructions for fixing, with links to the sysv and systemd books. I was thinking about merging the summary and instructions into a single paragraph because I usually use wide browser windows and there was often little more than one long line in each paragraph. But in a smaller window the paragraphs are easier to read so I decided to keep separate paragraphs. I'm also thinking about putting this on support (after revising the index, so not today!) to get feedback from those users who don't read -dev. ĸen -- The right of the people to keep and arm Bears, shall not be infringed. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
