Egregoros · Phoenix Framework

Post

Remote status

Context

Morgan

I don't use FreeBSD anymore, but something that always bugged me when I did was the issue of having to switch package repos from "quarterly" to "latest" and back again to be able to install certain software. This isn't clearly spelled out for new users, there's no mechanism to choose which repo you want in the installer, and it's assumed that any FreeBSD user just already knows about it and how to deal with it. It's clunky and annoying at the very least, and I feel it should be brought up during installation.

While the Handbook documents *how* to switch from "quarterly" to "latest", it doesn't explain that some packages are not available in one or the other, something that can confuse new users expecting all of their normal FOSS apps to be present in the package repo.

This was brought to mind while reading the Sylvie review by @distrowatch this morning.

https://distrowatch.com/weekly.php?issue=20260518#sylve

#freeBSD

DistroWatch

@distrowatch@mastodon.social remote

@kaidenshi It's a good point. I think new users will also be disappointed with how slowly Quarterly receives security updates. Which ,as you pointed out, isn't really explained well in the handbook.

Graham Perrin

@grahamperrin@mastodon.bsd.cafe remote

RE: https://fosstodon.org/@ianthetechie/116581088984501220

@distrowatch quarterly should not be significantly later for security.

The recent example discussed with Ian Wagner was an exception.

@kaidenshi

#FreeBSD #security

DistroWatch

@distrowatch@mastodon.social remote

@grahamperrin @kaidenshi Should not, but does. Quarterly often takes weeks to months (wnd of quarter) to get up to date with security fixes.

*sigh*Ber nard

@brnrd@bsd.network remote

@distrowatch @grahamperrin @kaidenshi that's not supposed to happen. Any security fix is expected to be merged into quarterly.
If it's not, or if the vuln is disclosed after the port is updated, a PR should fix that.

The vuln should be registered in vuxml, also possibly prompting quarterly merge.

dch

@dch@bsd.network remote

@brnrd and yet not all port maintainers do this @distrowatch @grahamperrin @kaidenshi

*sigh*Ber nard

@brnrd@bsd.network remote

@dch @distrowatch @grahamperrin @kaidenshi
Well aware of that...
I do my best for the ports I maintain, and for ports I'm using I will create vuxml entries.
The vuxml entry creation is right pain, we could do with a more streamlined solution (only ref. to external vulnerability db?) to make things easier.

Replying to @brnrd@bsd.network

dch

@dch@bsd.network remote

@brnrd if you have a suggestion for the upstream sources I can write a thing to simplify it. flua or perl probably.

Replies

Replying to @dch@bsd.network

*sigh*Ber nard

@brnrd@bsd.network remote

@dch

If you can create something that parses https://www.oracle.com/security-alerts/cpuapr2026.html, filters all MySQL Server and Client related vulns and populates the vuxml entry, that'd be something the port maintainer (@joneum) could use.

What I really meant is something to replace the vuxml process. Wasn't there something going on in the project about this exact issue?

I would be looking for something that pulls the info from an external resource, allows the port maintainer to filter out entries that don't apply on FreeBSD, and push it to something that's easy to query. The whole blockquote part in vuxml is duplication of effort, unnecessary in my view, unless the vuln is FreeBSD specific and not available in an external registry.
CVE? -> Look up in CVE databases
GHSA? -> Look up in Github
...?

Replying to @brnrd@bsd.network

*sigh*Ber nard

@brnrd@bsd.network remote

@dch @joneum and myself have a tough job maintaining the MySQL and MariaDB ports. There are multiple versions to maintain, they're big, have loads of options and dependencies, take long to build, ...
Having a cumbersome vuln registration process just isn't helping. The vuln registration must happen prior to updating (actually committing) the port so you have the vulnid from vuxml.

Replying to @brnrd@bsd.network

joneum

@joneum@bsd.network remote

@brnrd Thanks, as always, for creating the MySQL CVEs in vuxml.
There have been quite a few CVEs over the last few days, not only in the database ports, but also repeatedly in NGINX.

Replying to @joneum@bsd.network

dch

@dch@bsd.network remote

@joneum @brnrd I didn’t appreciate you needed these CVE/vuxml immediately. I had no time earlier this week but I will have a look at it the next few days, at least for next time…

Replying to @dch@bsd.network

feld

@feld@friedcheese.us remote

@dch @joneum @brnrd for a couple years I did a ton of work entering every possible CVE into vuxml and patching/merging into quarterly if it was missed. The process is so exhausting and clunky. We need real automation for it

Replying to @feld@friedcheese.us

*sigh*Ber nard

@brnrd@bsd.network remote

@feld @dch @joneum with registeree CPE it should be possible to automate at least some of the work. Similar to portscout?

Replying to @brnrd@bsd.network

feld

@feld@friedcheese.us remote

@brnrd @dch @joneum this was proposed ~10 years ago and abandoned for technical deficiencies in CPE I can no longer remember and I probably lost my IRC logs