Re: git: a580d36be4c7 - main - security/vuxml: add FreeBSD SA released on 2023-12-05

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?  Is something going to 
> get upset if I change the most recent entry to <lt>12.2_4</lt>?

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:




-- 
  Dan Langille
  dan@langille.org