On 2 Jul 2025, at 21:57, Mark Millard wrote: > The questions, for the example contexts: (1) FreeBSD-EN-25:09.libc . . . > > It lists: > > Branch/path Hash Revision > - ------------------------------------------------------------------------- > stable/14/ c43ae65b4b89 stable/14-n271080 > > Note: That description is trying to document both the kernel (/usr/src/sys/) > and the world (/usr/src/ other than sys/) vintage. It turns out here that the > errata is a world libc patch, not a kernel patch. By contrast (2) > FreeBSD-EN-25:11.ena has: > > Branch/path Hash Revision > - ------------------------------------------------------------------------- > stable/14/ 3f4a674a8ee4 stable/14-n271320 > > Which is a kernel patch, not a world patch. One could imagine some patches > that involve both.
Or neither. Maybe we publish ena or some subset of modules as sys-net-drivers, if we so choose. > How are PkgBase users to know the status relative to such a description that > is based on a git Hash and Revision? The format of our advisories will need to change for a pkgbase world. I don’t know how exactly that will work, but it seems reasonable that we may need to include pkgbase revision information as part of an SA/EN. > Another possibility is that specific FreeBSD-*-14.snap*.pkg names might > instead be listed for PkgBase identification. A PkgBase build can be made up > with a mix of .snap*.pkg suffixes across the various *.pkg files involved. > And there are hundreds of *.pkg files. So comparisons could be messy to deal > with. > > > Has the technique for this subject area been decided yet? If yes, what is the > intended technique? Speaking on behalf of secteam, not in the least. This is something we should probably add to our conversations, but I also think it is the kind of thing that we may have to work out in the moment as we stumble our way through it. Ideally, this will be done with plenty of time to get everything ironed out. Best, Gordon Hat: security-officer
signature.asc
Description: OpenPGP digital signature
