I'm posting this to both lfs-support and blfs-support. When I started here, things were a lot simpler - far fewer packages, a much more limited desktop, and not many security vulnerabilities were getting disclosed. In those days we had the lfs-security list for mentioning new vulnerabilities, but that has become defunct.
More recently, in BLFS we have mostly noticed updates which had security fixes, marked then in the Changelog as 'security update' or similar, and added them to the Security Vulnerabilities in the Errata. So, at the moment we have current vulnerabilities listed in http://www.linuxfromscratch.org/blfs/errata/stable-systemd/ and http://www.linuxfromscratch.org/blfs/errata/stable/ and we seem to have been doing this since BLFS-8.4. However, these reports tended to add new reports at the end, but update previously reported issues where they were so that the order was a bit random. In addition, details were usually sketchy (often the ticket had CVE numbers). On LFS, AFAICS we've stopped mentioning security issues except in the tickets for new versions. I've been hacking away on html for some changes to how we record these. The details are not yet all present (I've still got about the last 6 weeks to do), but there is enough to see where this is going. What I'm proposing is that we do this for both LFS and BLFS (at the moment, the only way to find LFS vulnerabilities after the event is to look at the links to the tickets from the Changelog). We will have pages for LFS and BLFS with lists of vulnerabilities between the release and the next release, and a consolidated list of all vulnerabilities. The pages for between releases are in alphabetical order by package, with newest vulnerability first if more than one, and the consolidated list is newest first. For the moment, the way in to this is: LFS - http://www.linuxfromscratch.org/lfs/advisories/ BLFS - http://www.linuxfromscratch.org/blfs/advisories/ Both of these point to 10.0 and consolidated. Once you find an advisory which is relevant to you, click on the link at the end (e.g. 10-024 for FreeType in BLFS) and you should get to the item in the consolidated list with (usually) one or more external links and links to the current pages in the sysv and Systemd development books. What I'm also proposing is to: (i) Add new 10.1 pages for the period from when 10.1 has been released up until we release 10.2, and add a label "Items between the releases of the 10.1 and 10.2 books" to the consolidated page above the existing items. (ii) After that, Muggins here will change the consolidated links (10.0 to 10.1 period) to point to the 10.1 books. This is because over time the books change. People who are still building 10.0 in the next few months should look at both the 10.0 page and also the 10.1 page (e.g. firefox-esr now gets a point release every four weeks, but instructions and dependencies which were present in February (10.1 release) might be very different by July and similarly some other packages may have been archived or forked and renamed. (iii) Eventually, the consolidated page will become rather large. At some point we can move older items to a different historical page. (iv) Critically, when this gets sorted (I need to look at indexing, and I'm aware the menu on the consolidated page is only relevant to BLFS) I'll comment out the existing advisories in the current BLFS Errata pages and add a message or link to the new advisories. One further thought: I've been catching up with details to provide links. For many of the items where upstream did not specify a severity level I've now found ratings at NVD. I'm sure that most of these ratings were not available when the packages were updated. So in general ratings will be assumed to be High in the absence of any other data. Obviously, glibc may be an exception for that (the only supported way to upgrade to a new version is to build a new LFS, although individuals with good *usable* backups might be able to update in place followed by an unclean shutdown, but no guarantees!). At the moment several items have 'Updated:' in their heading rather than 'Date:' to indicate that changes have occurred. The new pages include things which we ought to have noted, although sometimes we either missed them or failed to provide a vulnerability notification. Comments are welcome. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
