On Thu, 7 Jan 2021 at 06:30, Ken Moffat via blfs-dev <blfs-dev@lists.linuxfromscratch.org> wrote: > > My preference would be to have separate advisories for > *each* update. If we look at Arch, they have a series of detailed > advisories including summary, resolution, possible workaround, and > impact. Gentoo is somewhat similar but of course they deal with > multiple current versions of a package. Having such (separate) > advisories would be nice, but that implies a series of pages (perhaps > plain text) to link to from the Errata. > > For Arch, https://security.archlinux.org/advisory > > For Gentoo, https://security.gentoo.org/glsa > > They differ in what they show, but I note that both use a ccyymm-nn > identifier. I'd have thought that ccyymm-nnn might be simpler. > > The downside of doing this is that there is more work to do, and > slightly more data to store. But storing in date order (with a year > and number in the title/link) would make it easier for users to > review which items they have not caught up with (e.g. for the Arch > rsync advisory this week I'm not concerned about my systems because > I only use it internally). > > Oh, and although Errata are specific to a release of the book, I > suppose that the Security Vulnerabilities could become a link from > the errata to a new page (the overall list, e.g. starting from what > we have become aware of in January 2021) with links from that to > (plain text?) details for each item. i.e. transitionally 'For > Security Advisories starting from January 2021 see [new list]'. > > And I think that we could say something like (for resolution) 'apply > the patch added for fubar-2.3.4 or upgrade to a later version' or > 'update to xyzzy7.8.9 or later'. If the detailed advisory was plain > text, no links to the development books for the current details. > > Thoughts ? I'm sure several of us have different views about what > would be easiest for us to maintain, or about what would be easiest > for users to check.
In general, given that a new Book comes out every six months or so, (as in, BLFS is less of a "rolling release distro" than Arch or Gentoo ) is there a need to maintain Errata/SecAdvisory lists that spans multiple Books ? Let's say that there are a number of SecAdvisory-s for package P in LFS/BLFS 10.0. It's a pretty good bet that 10.1 will contain the package version that takes one to, if not past, the lastest Errata/SecAdvisory, in which case starting afresh for each Book release still feels right. Similarly, wouldn't the SVN version of the Book, which contained a package version update to address a SecAdvisory in package P, also be more likey to provide the full dependecy chain, for anyone wishing to upgrade just the one "compromised" package, at that point in time? Where I would express a prefernce, would be in having the Errata/SecAdvisory entries grouped by package, rather than by date, because it's in the nature of BLFS that different people will pick and choose different packages, so why split multiple changes to a a package across dates, unless the latest change rolls up all the previous ones? Jut my thr'pen'th, Kevin -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
