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
