Re: git: a580d36be4c7 - main - security/vuxml: add FreeBSD SA released on 2023-12-05
Date: Thu, 07 Dec 2023 01:10:31 UTC
On Wed, Dec 6, 2023, at 7:52 PM, Philip Paeps wrote: > On 2023-12-07 08:43:21 (+0800), Dan Langille wrote: >> On Wed, Dec 6, 2023, at 7:34 PM, Philip Paeps wrote: >>> On 2023-12-07 01:37:01 (+0800), Dan Langille wrote: >>>> On Tue, Dec 5, 2023, at 6:04 PM, Philip Paeps wrote: >>>>> The branch main has been updated by philip: >>>>> >>>>> [...] >>>>> >>>>> + <package> >>>>> + <name>FreeBSD-kernel</name> >>>>> + <range><ge>14.0</ge><lt>14.0_2</lt></range> >>>>> + <range><ge>13.2</ge><lt>13.2_7</lt></range> >>>> >>>> [...] >>>> >>>> I hope to avoid a situation where false positives continue until the >>>> user land and kernel are on the patch levels. >>> >>> This is the same problem we've had before, isn't it? >> >> Yes. > > Phew. I was worried I typo-ed something. ;-) > >>> Did we find an >>> actual solution to that, or do we have to wait until the next SA >>> brings >>> the freebsd-version numbers back in line? >> >> The world waited. ;) >> >>> In other words: is there anything I can do, right now, to make this >>> better for you? :-) >> >> It seems there kernel vulns and userland vulns. >> >> Why don't we check them and record them separately? > > I already record them separately in vuxml. If a vulnerability only > affects userland, I record <package><name>FreeBSD</name>[...]</package>. > If the kernel is affected I record > <package><name>FreeBSD-kernel</name>[...]</package>. > > Hmm ... is that the problem? Should I set the versions to the *kernel* > patch level for FreeBSD-kernel vulnerabilities? First, let's test if that fixes it. This fixes it for me: <range><ge>13.2</ge><lt>13.2_4</lt></range> given: [1:08 r730-03 dvl ~] % freebsd-version -ukr 13.2-RELEASE-p4 13.2-RELEASE-p4 13.2-RELEASE-p7 [sorry previous message went out too soon] > Is something going to > get upset if I change the most recent entry to <lt>12.2_4</lt>? That I don't know. VUXML entries have AMENDED values don't they? -- Dan Langille dan@langille.org