On Fri, Aug 1, 2025 at 12:15 PM Matthias Andree <[email protected]> wrote:
> Greetings, > > please see the attached commits I've made: > Thanks for the commits. I tend to monitor security/vuxml and those caught my attention. > > @Fernando: > - version ranges need to mention PORTEPOCH properly > Agree (more on this later) > > - if you have a <ge> and <lt> tag for a limited "in between these > versions" range, be sure to put them in the same range, else we will end > up with two overlapping but open-ended ranges, effectively listing *all* > versions vulnerable > Not always, but 99% of the time this will be true. Something like: <ge>3.0</ge> <lt>2.0</lt> Would mean a bug was present, then fixed, then reintroduced. If the <ge> value is smaller than the <lt> value, then yes, it is always an error. More on why I point this out a bit later. > > - remember to list linux/emulation ports, too > Agree, but not only that unfortunately. === Why is it difficult to get entries right? I think our approach to document ports vulnerabilities is fragile and also very time consuming. I tried to improve this by adding the "make newentry CVE_ID=..." feature to the security/vuxml but it is far from ideal. I have a WIP (for some time now) version of the port that tries to check if the port/version introduced in the new entry is correct. In order to do that, if "finds" the adequate port in the tree and checks PKGNAME. This is difficult and slow for many reasons: * PKGNAME in general is not the same as the upstream name reported in MITRE and friends * Finding the port is very slow with our current approach. Having a sqlite database for ports might speed up this and other issues ( https://reviews.freebsd.org/D42503) The XML version and our DTD are a bit complex: it is easy to make mistakes and difficult to automate cheks. The <ge><lt> issue is a good example. Also, take into account that the reminders in certain ports (like sqlite and others) is nice to have but I think it has limited usability: most entries *are not* filed by port maintainers hence, the person creating the entry is unlikely to go and have a look at the Makefile, I think. Last but not least, an upstream CVE affecting $foo might mean for us adding an entry for $foo, $flavor1-foo, $flavor2-foo, $flavor3-foo, $rl9-foo, $c7-foo... And also the derivatives. For firefox this means: librewolf, palemoon, waterfox, etc, etc. I will try and document the things you pointed out in the relevant section of the PH: https://docs.freebsd.org/en/books/porters-handbook/security/#security-notify-vuxml-db I think we could have some kind of nice pre-commit check list. I would love to have this automated, but improving "make validate" is not that easy. I think we should try to focus on improving our workflow here. It is almost impossible to keep up with the security vulnerabilities that happen in our over 30K ports. Thanks a lot for the fixes and for the things you pointed out! They are appreciated! Cheers. > > @Emulation: > - additional difficulty: linux-rl9-sqlite was merged into linux_base-rl9 > which has its own Makefile.version for several packages, and one > upstream version, so we don't have an easy top-level version to look at. > I guess we'll resort to PORTREVISION. Please check if sqlite3 was > patched vs. earlier linux_base-rl9 versions for the relevant > vulnerability or if it is vulnerable in RockyLinux9 and adjust the > vuln/2025.xml version after the fix. > > I've bluntly and summarily listed linux-c7 vulnerable, which has > 3.7.17-whatever but is also EOL and shouldn't be used. I guess we > should strip it from the distro. > > > ALSO, I've seen several entries where the <gt> tag is off. Some are > right and mention <gt>1.2.3</gt> where a bug was introduced in 1.2.4, > some seem implausible (navidrome >0.55 -- 0.55 was a big refactoring so > is far more likely to have introduced bugs than a later version - we > needn't care though because another vulnerability with wider range of > affected versions overlaps the other vuln/2025.xml entry.). > > Regards, > Matthias
