When will we get 15.1-RELEASE p7?

For a week I've been seeing warnings that 15.1 p6 is insecure but there's no sign yet of 15.1 p7. Anyone know what's holding it up?
 
Where do you see warnings?
I compiled p6 less than 2 weeks ago for the first time. It's probably p7 now or tomorrow. What's the usual time?
 
Where do you see warnings?
I compiled p6 less than 2 weeks ago for the first time. It's probably p7 now or tomorrow. What's the usual time?
Maybe after fix for unbound, expat and maybe some more are tested on stable/15 and MFS'ed to releng/15.1. So not sure when (if urgent critical fixes are NOT included, 3 days after at the minimum and fix for expat is MFC'ed to stable/15 around 18 hours before I'm writing this post).
 
From the freebsd-security mailing list, des@FreeBSD.org in answer to a question from someone who'd seen a warning about sqlite3 (the one base) in the periodic security emails:

Presumably a patch will be provided in the next round of security
advisories, but in the meantime you can safely ignore them. All of
these CVEs require the attacker to provide either a malicious database
file which causes sqlite3 to malfunction when read or a malicious query
which causes sqlite3 to malfunction when executed. The base system
version of sqlite3 is only used by Kerberos (mainly the KDC and admin
tools that access the KDC's database) and Kyua, and neither of those
operate on user-provided databases or execute user-provided queries.
 
Sorry if it's a stupid question but is there a way to find out when a new patch level is available to update to?
Maybe the best way would be to subscribe to freebsd-announce ML with receiving emails.
Unlike freebsd-security ML nor freebsd-security-notifications ML, freebsd-announce ML covers Errata Notices (ENs) in addition to Security Advisories (SAs).

And if I recall correctly, SAs and ENs are announced when binary upgrades are ready via freebsd-update and/or pkgbase. But possibly you need to wait until the mirror you're invited by load balancer finishes receiving updates.
 
Thanks. It's reassuring to know this particular set of bugs is not exploitable from the way FreeBSD uses the program, but it would have helped to have that information as part of the explanation on the security pages about the bugs rather than relying on people reading mailing lists they're not on and probably wouldn't want to be on.

I hope I'm not seen as complaining, but I've had an anxious few days not understanding why I'm being warned about a problem I can't fix which isn't really a problem at all.
 
Maybe the best way would be to subscribe to freebsd-announce ML with receiving emails.
Unlike freebsd-security ML nor freebsd-security-notifications ML, freebsd-announce ML covers Errata Notices (ENs) in addition to Security Advisories (SAs).

And if I recall correctly, SAs and ENs are announced when binary upgrades are ready via freebsd-update and/or pkgbase. But possibly you need to wait until the mirror you're invited by load balancer finishes receiving updates.
I clicked on your link and selected 'Browse the archives' but after looking through a number of the month links in the period column I saw no reference to a new patch level being announced.

Did I miss something or am I doing something wrong?
 
And if I recall correctly, SAs and ENs are announced when binary upgrades are ready via freebsd-update and/or pkgbase.
Unfortunately, not always. Several times recently I've received warnings of a vulnerability in the daily security cron job because a CVE has been made public, but a fix is not ready. In this case it's because the security team have checked and the vulnerabilities don't affect the way FreeBSD uses sqlite3 so a patch isn't needed, but I still get a warning because the CVEs are present in the current version even though my system is not vulnerable.
 
Several times recently I've received warnings of a vulnerability in the daily security cron job because a CVE has been made public, but a fix is not ready.
That almost sounds like noise and I'm kind-of wondering some opinions about CVEs now; is this related to nginx -> freenginx split?

There's always going to be something discovered that can be categorized as a security issue by someone/thing, and more known beyond that that aren't public. Everything worthwhile wants to patch as soon as possible, and anyone on cutting-edge knowledge to know they need protection from fresh CVEs likely can compile the fix and not need to wait for someone else to binary it.

What good's a warning you can't do anything about? Security's a myth :p
 
Back
Top