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: > > > > I'm thinking the format will be something like the following (not > > necessarily what I originally suggested). > > > > (title: BLFS Security Advisories from September 2020 onwards) > > > > (heading: BLFS-10.0 was released on 2020/09/01 > > - intersperse a new heading for each release) > > > > For each advisory: something like (not sure how this will look, > > detail may change a bit, maybe initially with variations in the > > layout for people to form opinions on what looks best) > > > > SA 20YYMMNN Vulnerabilities in FuBar before version 1.2.3. > > > > (some details, according to what is available for individual > > advisories.) > > > > (possible links to CVEs or other notifications - sometimes there > > might be several CVEs) > > > > To fix this, (either: mention some workaround, or) update to > > FuBar-1.2.3 or later using the instructions in the development > > books: [link for sysv labelled as FuBar (sysv)] [link for systemd > > labelled as FuBar (systemd)] > > > > 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, > > FooBar > > 20YYMMNN: versions before 1.2.3. > > (some details, according to what is available for individual advisories.) > (possible links to CVEs or other notifications - sometimes there might > be several CVEs) > > Fix: details of fix. > > > 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,
thanks for opening the discussion. I had thought about ordering so that newest was first, oldest last (like the book's changelog) but in the context of tring to keep a continuos list of advisories across book releases it initially seemed a bit weird to me. I suppose a complete list with top=latest, bottom=oldest is not impossible. What I'm (currently) not keen on is ordering by package name, with versions for each package in top=latest order because (a) Over time, I think packages have occasionally been renamed or replaced by forks with a new name (e.g. Qt webkit package was replaced by webengine and that fixed a lot of old vulnerabilites). (b) Sometimes, an advisory affects multiple packages. The most obvious in the current book have been some of the firefox updates which also had security fixes in the separate javascript (JS78). That suggests two advisories for each of them. (c) A single sequence in numeric order (whatever is decided on) is fairly easy to update without missing numbers or re-using them. 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. 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. The thing about a prototype is that it shows that things like layout and numbering which appear to an individual to be "somewhat obvious" may have more alternatives than dreamt of. Thanks. ĸ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
