Security - PHP RCEs reported

mtu said:
Indeed. The challenge wasn't fundamentally different for Debian, and they had packages in the repos within 1 hour.
Click to expand...

I think the FreeBSD ports commit was even earlier. But that's not packages. The way that dependencies work in pkg would have to be re-worked to reliably integrate updates single packages into the larger (previous) repository. That's my understanding.

Nontheless in this particular case I was indeed able to build php directly and it "fit". Maybe I should have made my packages available for other to just drop in from the commandline, but I don't have all releases.
 
> For me it seems to be random, which builds are started first and therefore finish first. Could anybody clarify?

Maybe, coming out of this event, the great developers of FreeBSD will issue some manner of dissertation about this and what was learned.
 
cracauer@ said:
Well, FreeBSD has the hardware to build packages for everything. And the software to do it efficiently - when building all paclages. There is just a big, big pile of issues getting in the way of quickly building individual packages and inserting them into the pkg mirrors. By-hand intervention worked for some targets but not for others in this case. The expectations are not unrealistic, they are just not currently realized.
Click to expand...

Well then this is something we as a community should look at more deeply. Maybe as an official target for the Foundation themselves.
To have mission critical or security related PKGs available in short time, is absolutely fundamental necessary in these wildly fast situations nowadays.
Waiting 2 days to get those patches is simply unacceptable.

Another example: archivers/brotli, CVSS 9.2, Port updated on 23. Okt. 2026, 22:53 , No PKGs available

How could we archive this goal an make FreeBSD great again? :)
I am willing to help.
 
sko said:
also relevant:
docs.freebsd.org

Appendix A. Obtaining FreeBSD

How to get FreeBSD: Distribution services, mirrors, code repositories, and SSH keys
docs.freebsd.org docs.freebsd.org


So it may take some time for your local mirror to sync.

Caching by fastly may also be involved (depending on how quick fastly handles upstram changes)
Click to expand...
I don't know if we are ever going to find out what was the root cause of this delay in patch delivery but from what I've gathered the patch took a while not just to be compiled but validated, which I can understand. I saw Sury's repo (PPA repo for Ubuntu's alternative PHP) being built and finished at around 17.00 UTC (from memory) and FreeBSD having it a couple of hours later (e.g https://pkg-status.freebsd.org/beefy23/data/151amd64-default/792be2623dc0/logs/php85-8.5.12.log). However, one thing is compiling and another is the delivery.

It's an unknown how fast are the links between the building machines and the CDN. And then, how the CDN purges its cache or storage to allocate the new packages. My guess is lots of "static" or "semi-static" things like OS packages (FreeBSD or else) are cached. And no-one in the FreeBSD org had the capacity to purge such cache and land the new packages in time. This is an inferred assumption solely based on comments in this thread and reddit comments, so pure speculation based on what others were reporting at the time. Take it with a metric ton of salt, not just a pinch. As it can be read here some people got patches quicker than others based in "latest" or "quarterly" and OS version, but probably physical location was a factor too, meaning the CDN had some involvement. I want to think the caching mechanism was not selective to individual packages, meaning as soon as a new package hits the directory whatever is cached related to that gets pruned, quite the contrary it was a "full directory" cache and whenever the config said "it's expired", it did in block (not per package). Again, another assumption, this time coming from my rear end with no facts to sustain it.

I know there's very diligent people in the project, and everyone does their best, which is the reason I am still surprised it took so long to get the patches in the machines. A clarification on what happened would be very welcome. Sometimes it's hard to sell FreeBSD as an OS to work with, and things like this do not help. I wasn't building my own packages, now I am, and I am not a shop, I just deal with my personal projects.
 
drhowarddrfine said:
We will hear from the developers eventually. In the meantime, let them do their work.
Click to expand...

Hopefully they have heard what we have discussed here. To be clear:
I am very grateful about the FreeBSD project at all since a very long time and I do respect the hard work from all the committers and developers.
Lets see and wait. Thank you for the continuous efforts, especially nowadays.
 
It's not a matter of understanding the users. Everybody want faster packages in general and for serious vulnerabilities the emergency fixes. There are serious technical obstacles and few developers understand some of the key issues.
 
If this worries you there is a simple solution - set up ports-mgnt/poudriere to build the packages you use. I realised I had to do this years ago when I discovered ports sometimes take a while to filter through to packages. I even bought a fast machine to do it. In time that machine became my desktop and poudriere became a VM within it - still fairly fast. When the PHP bug hit and I found out the update was in ports I just launched the VM and had 130 packages, including perl, apache, PHP and all their requirements built in about 90 minutes. Half an hour later all my servers were updated and back on line.

Don't curse the darkness. Light a candle.
 
kjpetrie said:
If this worries you there is a simple solution - set up ports-mgnt/poudriere to build the packages you use. I realised I had to do this years ago when I discovered ports sometimes take a while to filter through to packages. I even bought a fast machine to do it. In time that machine became my desktop and poudriere became a VM within it - still fairly fast. When the PHP bug hit and I found out the update was in ports I just launched the VM and had 130 packages, including perl, apache, PHP and all their requirements built in about 90 minutes. Half an hour later all my servers were updated and back on line.

Don't curse the darkness. Light a candle.
Click to expand...
Precisely what I did after 2 days of waiting. It took a few hours (7-8) to build my package selection. However, the expectation many users have is not needing to resource to poudriere and build packages. In fact, I've "survived" until this point without this for a decade +. This is a hard selling point to be honest. Having some delay is acceptable most of the time, but becomes crucial not having one in moments like this.

Of course, if one is dealing with an enterprise environment, a self hosted repo becomes interesting for many reasons, among them the case in hand. And this case has been a bit special for several reasons.
 
You must log in or register to reply here.
Back
Top