Planet

Last updated: 2026-09-10 16:45:01 UTC

FBI Probes Service Selling 153M+ Drivers Licenses

Post by Brian Krebs via Krebs on Security »

A new identity theft service launched on the dark web this week is selling digital scans of more than 153 million drivers licenses from people in the United States and Canada. Based on interviews with individuals whose licenses are available for purchase on this service, it appears to be siphoning images collected by a widely-used identity verification company based in Louisiana. KrebsOnSecurity also has learned that the New Orleans field office of the Federal Bureau of Investigation (FBI) today launched an official inquiry into the source of the images.

A record available at this identity theft service that includes the drivers license for U.S. Defense Secretary Pete Hegseth, one of several high-ranking U.S. government officials whose drivers licenses can be found for sale.

On Monday, Aug. 31, a source alerted KrebsOnSecurity to a service advertised by a new user on the Russian cybercrime forum Exploit, offering access to digital scans of identity documents on more than 170 million people in North America. The source brought it to my attention because the proprietor of this identity theft service offered my Virginia drivers license as a free sample in their initial sales thread on Exploit.

The service, dubbed Nexus, claims to have more than 153 million drivers licenses for people in the United States and Canada, as well as more than 10 million identification cards; more than three million travel documents and/or international IDs; and at least 579,000 medical cards.

A quick look around Nexus finds they are likely not exaggerating about that 153 million number: Running a blank search in Nexus (with no search parameters entered) returns approximately 11.5 million pages of results, with roughly 15 results displayed per page. It includes documents from people in both Canada and the United States, but the bulk of these records are on Americans: searching for just Canadian drivers licenses returns approximately 1.1 million results, with the largest concentration from Ontario (473,673 records).

Curiously, the identity records include not only drivers licenses but also marijuana dispensary cards. Some of the records list their “source” as “CDL,” presumably short for “commercial drivers license.” Other records carry the source notation of “CAC,” which may refer to Common Access Cards, government issued identity cards that grant physical access to government buildings and secure rooms.

The people behind Nexus claim the license images are coming from an active breach at “a major identity verification company” whose customers include multiple Fortune 500 companies.

The record totals listed by the Nexus identity theft service. The number of drivers license records increased by nearly 400,000 in the span of just 24 hours.

“We have been continuously exfiltrating new data for over a year into our private database,” the service enthused in its introductory post on Exploit. “Records are available to preview before purchase with pertinent information redacted. Customer photos are displayed if available.”

Indeed, over the past 24 hours, the number of drivers license records listed as available in Nexus has increased by nearly 400,000, suggesting that freshly stolen license data is being harvested and uploaded to this service on a semi-regular basis.

The record featuring my drivers license includes six image files: three pairs of photos of the license’s front and back, a basic image scan, as well as infrared and ultraviolet versions of the same images. A date and timestamp is appended to each image file, and the timestamp on my license scan corresponds to a date in June 2025 when I took a flight to the midwest United States to attend a family funeral.

Some of the 153 million+ license scans — including mine — feature six image files with date and timestamps appended to the filenames. Not all records include photos, and some that do feature photos do not display the associated filenames.

Intent on discovering the source of this data, KrebsOnSecurity asked more than a dozen friends and family members for permission to search for their licenses in this service. Each person whose license could be found (nine of them) confirmed having traveled on or very close to the dates in the timestamps attached to their images. It is unclear what timezone these timestamps are in, but from reviewing car rental records shared by several people who helped with this research, it appears the timezone is set to Greenwich Mean Time (GMT).

At first, I thought the source of the data might have something to do with airports. However, that theory went out the window when it became apparent there were no passports in this data set. Also, only some of those who helped with this research said they showed their drivers license at the airport on the day of their travel. One person whose license was in Nexus hadn’t flown at all recently, but was renting a car from Hertz for several months around the date of their timestamp.

Two of those who agreed to help are federal employees who said they shared other forms of government identification when passing through airport security. However, those individuals each said they shared their state-issued drivers licenses later that day when renting vehicles at their respective destinations, and that both rented their cars from Hertz.

After finding a note in my calendar for the day of my June 2025 flight reminding me to bring my passport, I remembered that I also never actually shared my drivers license when I went through security at Reagan National Airport on that day because I did not yet have a Real ID, a security-enhanced drivers license that is now required by the Transportation Security Administration (TSA) for all domestic travel. Instead, I showed the TSA agent my government-issued U.S. passport.

Here’s where it gets interesting: I was able to find my mother’s drivers license in this service as well, and the timestamps for her images are just a few seconds apart from mine. That’s notable because we both handed our licenses to the Hertz rental car representative at the same time.

According to my mom, the only place she gave her drivers license to that day was the rental car company, and if memory serves that is also true for me. I don’t recall if the rental car representative inserted our licenses into any kind of machine, but I remember they held onto them for several minutes behind the counter while we were signing various forms. KrebsOnSecurity sought comment from Hertz and will update this story in the event they reply.

Zach Edwards is a well-known security and privacy researcher who recently launched a service called DecryptAds to help people better understand how online advertisers are tracking them. A scan of Edwards’s drivers license is available for purchase on this identity theft service, and Edwards said the timestamp on his record corresponds to the middle of a trip last month to Las Vegas for the annual DEFCON security conference.

Edwards told KrebsOnSecurity that although he did not rent a car in Vegas, he did hand over his license at the TSA checkpoint, at a marijuana dispensary in Vegas, and at his hotel (the Aria). But he said the only one of those three that for sure scanned his ID in some kind of device was the dispensary.

To enter Planet13’s weed dispensary in Las Vegas, one must pass through a red telephone booth. Image: Zach Edwards.

Edwards said the dispensary he visited that day was Planet13, a multi-state chain with stores in California, Florida, Illinois and Nevada. In 2022, the New Orleans-based identity provider idscan.net published a press release announcing an exclusive identity verification agreement with Planet13’s dispensaries nationally. IDScan says it processes ID verification for more than 1,000 marijuana dispensaries in 19 U.S. states.

The “trust” page of idscan.net states that the company provides identity verification services for numerous big brands, including Hertz, Target, Fedex, Motorola Solutions, the financial services giant Jack Henry, and Caesars Entertainment. And as idscan.net’s own documentation states, the technology scans IDs with both infrared and ultraviolet light. Idscan.net says the company’s systems and technology perform more than 21 million verifications monthly, at more than 20,000 locations around the world.

Image: idscan.net.

Contacted by KrebsOnSecurity, idscan.net said it was investigating the matter, but the company has not yet shared an official statement or a substantive reply to specific questions sent via email.

“At this point I’m not able to share any additional information, but the updates you have provided have been welcome, and helpful to our team’s investigation,” wrote Jillian Kossman, a marketing and operations leader at idscan.net.

During the course of my research for this story, word got around to the FBI that I was poking at the apparent source of this new identity theft service’s data. Probably they were tipped off when I shared with a trusted source that Nexus also is selling the drivers license information for the assistant director of the FBI (I did not find FBI Director Kash Patel’s license in Nexus).

Earlier this afternoon, I was added to a conference call with a half-dozen FBI agents, including senior leaders from the agency’s cyber division. During that call, the FBI shared that earlier today their New Orleans field office opened an official investigation into an apparent breach involving idscan.net.

Edwards said that as more in-person and online experiences require sharing drivers licenses, vendors who collect this sensitive data need to be held to a higher standard.

“This episode should further strengthen the resolve for people who are fighting back against online ID schemes which are requiring countless providers to ask for drivers licenses in order to access services under the guise of protecting kids,” Edwards told KrebsOnSecurity. “These systems are putting sensitive data into more and more 3rd party vendors, and we don’t have nearly the oversight to ensure they are safe.”

Larry Baldwin is principal intelligence researcher at the cybersecurity firm Cybera. Baldwin said a front and back scan of his drivers license available at Nexus contains timestamps that correspond to the date of a car rental from Hertz on a recent vacation.

Baldwin said the Nexus identity theft service presents multiple serious security and privacy threats, noting that state-issued drivers licenses are commonly used as proof of one’s identity when opening new lines of credit. Baldwin said the service could also dangerously expose many people who do not wish to be found but who cannot meaningfully change their appearance (or at least not enough to fool today’s AI-based image matching tools).

This category of people, he said, includes those fleeing domestic violence, and even people who have been assigned a whole new life and identity as part of the federal government’s witness protection program, which is generally reserved for criminal defendants in racketeering and conspiracy investigations who agree to cooperate with federal authorities.

“Just when it seems like we’re making some headway in improving authentication controls through drivers license verification systems, this happens and the very thing those improvements are dependent on are compromised,” Baldwin said.

Update, Sept. 8: IDscan.net published a brief notice saying it has “determined that an unauthorized third party may have access and/or copied certain customer information, including full names and drivers license or other government-issued identification numbers.” The statement said IDscan.net is notifying affected individuals and offering credit protection services.

Update, Sept. 2, 6:05 p.m. ET: A spokesperson for Caesars Entertainment said Caesars has not been a client of IDScan.net and has not used VeriScan since February 2025, despite IDScan.net listing them as a client on their website. That person said Caesars had no active VeriScan accounts at the time of the incident and did not authorize IDScan.net to retain data from its accounts, and that IDScan.net said the incident should have no impact on Caesars Entertainment.

Update, 8:56 p.m. ET: Shortly after this story was published, the Nexus identity theft service website vanished from the darkweb, replacing its login page with a plain text message that reads, “This service is no longer available.”

This is a potentially fast-moving story. Any changes or updates will be noted here along with a timestamp.

Top

Git Worktrees: mehrere Branches gleichzeitig auschecken

Post by Kristian Köhntopp via Die wunderbare Welt von Isotopp »

Ein Git-Repository kann mehrere Arbeitsverzeichnisse haben. Mit git worktree liegt main zum Beispiel in ~/Source/project, während der Branch new-feature gleichzeitig in ~/Source/project/.worktrees/new-feature ausgecheckt ist.

Das ist nützlich, wenn im Hauptverzeichnis ein Server läuft, ein Test lange arbeitet oder man eine angefangene Änderung nicht wegräumen will, nur um kurz einen anderen Branch anzusehen. Ein zweiter Clone würde ebenfalls funktionieren, dupliziert aber die Repository-Daten und muß separat aktuell gehalten werden. Worktrees teilen sich dagegen dasselbe Repository.

Worktrees und Branches

Ein Branch ist in Git zunächst nur ein beweglicher Name für einen Commit. Ein Worktree ist ein Arbeitsverzeichnis mit ausgecheckten Dateien, einem eigenen HEAD und einem eigenen Index, also einer eigenen Staging Area.

Im Normalfall ist jeder Worktree mit genau einem Branch verbunden. Git läßt denselben Branch nicht gleichzeitig in zwei Worktrees auschecken. Sonst könnten zwei Arbeitsverzeichnisse unabhängig voneinander versuchen, denselben Branch-Zeiger zu verschieben.

Für die Beispiele sieht die Verzeichnisstruktur so aus:

~/Source/project/ main
└── .worktrees/
 ├── new-feature/ new-feature
 └── linear-feature/ linear-feature

Das Projekt enthält diesen Eintrag in .gitignore:

/.worktrees

Der führende Slash beschränkt die Regel auf .worktrees im Wurzelverzeichnis des Projektes. Git ignoriert dadurch die Arbeitsverzeichnisse der anderen Worktrees im Checkout von main.

Einen Feature-Worktree anlegen

Wir beginnen im bestehenden Checkout. main zeigt auf den Commit, von dem das Feature abzweigen soll:

cd ~/Source/project
git switch main
git status --short
git worktree add -b new-feature .worktrees/new-feature

-b new-feature legt den Branch an. Das letzte Argument bestimmt das Arbeitsverzeichnis. Ohne weiteren Commit oder Branch als Startpunkt verwendet Git dabei HEAD, hier also den aktuellen Stand von main.

Das Verzeichnis ist danach ein vollständiges Arbeitsverzeichnis:

cd ~/Source/project/.worktrees/new-feature
git branch --show-current

Die Ausgabe ist new-feature. Änderungen in diesem Verzeichnis gehören zu diesem Worktree. Das gilt auch für den Index: git add im Feature-Worktree verändert nicht die Staging Area im Hauptverzeichnis.

Implementieren, testen und committen

Nun wird das Feature wie in jedem anderen Checkout bearbeitet. Die konkreten Dateien und der Testbefehl hängen vom Projekt ab:

cd ~/Source/project/.worktrees/new-feature
$EDITOR src/feature.py tests/test_feature.py
pytest -v
git status --short
git add src/feature.py tests/test_feature.py
git commit -m "Implement new feature"

Der Commit verschiebt den Branch new-feature. main bleibt unverändert. Die beiden Branches zeigen jetzt auf unterschiedliche Commits, obwohl ihre Worktrees dasselbe Git-Repository benutzen.

In main mergen und aufräumen

Wir wechseln nicht mit git switch zwischen den Branches, sondern gehen einfach in den bereits vorhandenen Worktree von main:

cd ~/Source/project
git switch main
git merge --no-ff new-feature
pytest -v

--no-ff erzeugt hier absichtlich einen Merge-Commit. Das Feature bleibt dadurch als eigener Zweig in der Historie sichtbar, auch wenn ein Fast-Forward möglich gewesen wäre.

Erst wenn der Merge und die Tests sicher sind, räumen wir auf:

cd ~/Source/project
git worktree remove .worktrees/new-feature
git branch -d new-feature

Die Reihenfolge ist wichtig. Solange der Branch im Worktree ausgecheckt ist, läßt Git ihn nicht löschen. git worktree remove verweigert außerdem ohne --force das Entfernen eines Worktrees mit nicht committeten Änderungen, und git branch -d verweigert das Löschen eines nicht gemergten Branches. Diese Sicherungen sollte man nicht ohne konkreten Grund abschalten.

Lineare Historie mit Rebase und Fast-Forward

Im zweiten Beispiel soll kein Merge-Commit entstehen. Wir legen wieder einen Worktree samt Branch an und entwickeln darin:

cd ~/Source/project
git worktree add -b linear-feature .worktrees/linear-feature

cd .worktrees/linear-feature
$EDITOR src/linear_feature.py tests/test_linear_feature.py
pytest -v
git add src/linear_feature.py tests/test_linear_feature.py
git commit -m "Implement linear feature"

Währenddessen kann main durch andere Arbeit weitergelaufen sein. Vor dem Merge setzen wir die Feature-Commits deshalb auf den aktuellen Stand von main:

cd ~/Source/project/.worktrees/linear-feature
git rebase main
pytest -v

Rebase nimmt die Commits, die nur auf linear-feature existieren, und spielt sie auf dem aktuellen Commit von main neu ab. Dabei entstehen neue Commit-IDs. Das ist für einen lokalen, noch nicht veröffentlichten Feature-Branch unproblematisch.

Falls Konflikte auftreten, werden sie im Feature-Worktree aufgelöst. Danach geht es mit git rebase --continue weiter. Nach erfolgreichem Rebase kann main ohne Merge-Commit vorwärtsgeschoben werden:

cd ~/Source/project
git merge --ff-only linear-feature
pytest -v
git worktree remove .worktrees/linear-feature
git branch -d linear-feature

--ff-only ist hier die entscheidende Kontrolle. Ist main seit dem Rebase erneut weitergelaufen, bricht Git ab, statt doch einen Merge-Commit zu bauen. Dann wird der Feature-Branch noch einmal auf main rebased.

Worktrees verwalten

Kommando Zweck
git worktree list Alle Worktrees mit Pfad, Commit und Branch anzeigen
git worktree add -b NAME PFAD Neuen Branch und Worktree von HEAD anlegen
git worktree add PFAD BRANCH Bestehenden Branch in einem neuen Worktree auschecken
git worktree remove PFAD Einen sauberen Worktree entfernen
git worktree move PFAD NEUER-PFAD Einen Worktree verschieben
git worktree lock PFAD Automatisches Aufräumen eines zeitweise nicht erreichbaren Worktrees verhindern
git worktree unlock PFAD Einen gesperrten Worktree wieder freigeben
git worktree prune Verwaiste Verwaltungsdaten gelöschter Worktrees entfernen
git worktree repair Verknüpfungen nach manuellem Verschieben reparieren

Für Skripte liefert git worktree list --porcelain ein stabiler zu verarbeitendes Format. Im Alltag reichen meist add, list und remove.

Wie Worktrees implementiert sind

Logisch kann man sich einen Worktree als weiteren Clone vorstellen, dessen .git auf das Repository im Hauptverzeichnis zeigt. Das Bild erklärt den wichtigsten Effekt: Jeder Worktree hat eigene ausgecheckte Dateien, aber alle sehen dieselben Commits und Branches.

Technisch ist .git im verknüpften Worktree jedoch kein Symlink und kein Verzeichnis, sondern eine Textdatei. Sie verweist auf ein Verwaltungsverzeichnis unter .git/worktrees/ des Haupt-Worktrees, ungefähr so:

gitdir: /home/user/Source/project/.git/worktrees/new-feature

Dieses Verwaltungsverzeichnis enthält unter anderem den eigenen HEAD, den eigenen Index und einen Rückverweis auf den Worktree. Eine commondir-Datei verweist von dort auf das gemeinsame .git-Verzeichnis. Objekt-Datenbank, Branches, Tags und die meisten anderen Repository-Daten werden gemeinsam benutzt; Arbeitsdateien, HEAD und Index sind pro Worktree getrennt.

Darum braucht ein Worktree kaum zusätzlichen Platz jenseits seiner ausgecheckten Dateien. Darum sieht er neue Commits und Branches sofort. Und darum sollte man ihn mit git worktree remove statt durch bloßes Löschen des Verzeichnisses entfernen: Git muß nicht nur Dateien, sondern auch seine Verwaltungsdaten aufräumen.

Top

Microsoft Plugs Nearly 1,000 Security Holes

Post by Brian Krebs via Krebs on Security »

Microsoft Corp. today issued updates to plug at least 974 security holes in its Windows operating systems and other software, by far its biggest single patch batch ever. Microsoft says artificial intelligence is helping to speed the discovery of vulnerabilities, but security experts warn that many organizations already are struggling to prioritize the more human-intensive endeavor of testing and deploying so many fixes each month.

Image: Shutterstock.com, Kirill Makarov.

This month’s patch bundle obliterates the software giant’s previous record set in July, when it released updates for at least 570 security vulnerabilities. September’s Patch Tuesday brings this year’s total to more than 2,600, more than twice Microsoft’s previous record-setting patch year in 2020 (1,245) and with three more months to go.

There are two “zero-day” flaws fixed this month that are being actively exploited: both CVE-2026-81963 and CVE-2026-85880 allow an attacker to elevate their privileges on Windows system.

Fully 113 of the bugs addressed today earned Microsoft’s “critical” rating, meaning they could be abused by malware or miscreants to seize control over a vulnerable Windows machine with little or no help from the user.

Among the more serious critical flaws this month is CVE-2026-69730, a DNS weakness present in Windows Server 2012 onward and on Windows 10. Microsoft warns that an unauthenticated attacker could leverage this weakness simply by sending a specially crafted packet to an affected system, and that it is likely to be exploited.

Also scary is CVE-2026-69829, a critical, remote code execution flaw in the Windows Shell. This vulnerability has a CVSS base score of 9.8 (10 is the most severe), and can be exploited with low attack complexity, no privileges, and no user interaction.

Microsoft’s summary of the security updates released today. Image: msrc.microsoft.com.

Microsoft is hardly alone in shipping monster patch bundles lately. Many other large software companies, including Adobe, Cisco, Google, Mozilla and Oracle, all have recently credited AI-assisted research with increasing their patch cadence and volume (Google said today it is now going to ship security updates every two weeks).

Tyler Reguly, associate director of security research and development at Fortra, said one core challenge with deploying Windows updates is that they need to be tested before being installed across an organization because not all third-party software works seamlessly in the face of changes to the underlying operating system.

“It’s time to put our CISOs and CSOs on notice,” Reguly said. “How are you helping your teams through these difficult times? Do you have your teams deploy after hours and on weekends to avoid disruption to the business environment? Do you reward them for that effort? Time to dig into your budget and buy dinner for your teams that are working on Saturday to get patches rolled out before users return to work on Monday.”

Satnam Narang is senior staff research engineer at Tenable. Narang said it’s important to recognize that while the number of vulnerabilities being patched by Microsoft is rising, the number of flaws that can and will affect most organizations remains quite low.

“AI-assisted vulnerability discovery in 2026 is creating larger haystacks, but it isn’t finding more needles,” he said. “It’s critical that organizations understand which vulnerabilities actually apply to them, whether they pose a threat by being reachable and exploitable, and prioritize remediation based on this risk context.”

Of course, regular Windows users don’t need to test patches before deploying them, but they still need to open Windows Update periodically or else assent to the program’s nag notices about pending updates. And at the rate these Windows patch releases are ballooning in size, it’s probably best not to let them pile up month after month.

Enterprise Windows admins will want to keep an eye on askwoody.com for news of any updates that appear to be causing problems. As always, the SANS Internet Storm Center has a per-patch breakdown ordered by severity and urgency.

Top

FreeBSD 14.5-RELEASE Available

Post by FreeBSD Newsflash via FreeBSD News Flash »

Release Information page.
Top

Valuable News – 2026/09/07

Post by Vermaden via 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗 »

The Valuable News weekly series is dedicated to provide summary about news, articles and other interesting stuff mostly but not always related to the UNIX/BSD/Linux systems. Whenever I stumble upon something worth mentioning on the Internet I just put it here.

Today the amount information that we get using various information streams is at massive overload. Thus one needs to focus only on what is important without the need to grep(1) the Internet everyday. Hence the idea of providing such information ‘bulk’ as I already do that grep(1).

The Usual Suspects section at the end is permanent and have links to other sites with interesting UNIX/BSD/Linux news.

Past releases are available at the dedicated NEWS page.

UNIX

FreeBSD Git Weekly: 2026-08-24 to 2026-08-30.
https://freebsd-git-weekly.tarsnap.net/2026-08-24.html

Caching freebsd-update(8) and pkg(8) Files with NGINX.
https://omussell.github.io/fbsd-update-cache/

BaroPAM Installation Guide on FreeBSD.
https://mc529.tistory.com/1567

LibreOffice 26.8 is Out – Local First – No AI.
https://theregister.com/applications/2026/08/28/libreoffice-26.8-out/5293301

Call for Testers with NVMe on FreeBSD.
https://lists.freebsd.org/archives/freebsd-current/2026-September/010763.html

Offshoots of Cancelled TrueNAS CORE Upgrade to FreeBSD 15.
https://theregister.com/storage/2026/09/02/offshoots-of-cancelled-truenas-core-upgrade-to-freebsd-15/5293725

Report periodic(8) Sends Anyway.
https://vivianvoss.net/blog/periodic-sheet

FreeBSD Release Cycle: What It Means for Your Upgrade Schedule.
https://klarasystems.com/articles/freebsd-release-cycle-and-upgrade-schedule/

Wine 11.17 Released with Initial Support for Display Mode Emulation.
https://phoronix.com/news/Wine-11.17-Released

AppJail 5.5.0 Released.
https://github.com/DtxdF/AppJail/releases/tag/v5.5.0

NetBSD 9.5 Released.
https://netbsd.org/releases/formal-9/NetBSD-9.5.html

NetBSD 11 from Scratch.
https://meanmicio.org/2026/09/06/netbsd-11-from-scratch/

AMD Based FreeBSD Desktop Reloaded.
https://vermaden.wordpress.com/2026/09/06/amd-based-freebsd-desktop-reloaded/

FreeBSD Introduces Similar to top(1) Tool nfsdtop(8) with NFS Server I/O Using dtrace(1).
https://cgit.freebsd.org/src/commit/?id=60c7313074b93adf4ea70ff44b78b3b4fc15c29f

FreeBSD Git Weekly: 2026-08-31 to 2026-09-06.
https://freebsd-git-weekly.tarsnap.net/2026-08-31.html

Moving from Binary Packages to pkgsrc.
https://eugene-andrienko.com/2026-09-07-bsd-pkgsrc-ports.html

UNIX/Audio/Video

FreeBSD Basics – Part 1 – System /bin/sh Shell.
https://youtube.com/watch?v=sbvzOGv8lm8

BSD Now 679: It Also Goes to 11.
https://www.bsdnow.tv/679

Hardware

ThinkPad Endgame.
https://williamjansson.com/posts/thinkpad_endgame/

How EV Tires are Made Differently from Regular Tires?
https://youtube.com/watch?v=lfjc4XyU0Og

Life

What the Fuck Happened to Nerds.
https://mrmarket.lol/what-the-fuck-happened-to-nerds/

Can Tech Legends Find the Liar – Mafia Episode 1.
https://youtube.com/watch?v=EDCwQe7P8T0

Other

Balkanization of Virtualization will Dethrone VMware.
https://theregister.com/virtualization/2026/08/31/balkanization-virtualization-vmware/5292488

82MHz – Linkdump No 123.
https://82mhz.net/posts/2026/09/linkdump-no-123/

Porsche Unleashed.
https://www.filfre.net/2026/09/porsche-unleashed/

Usual Suspects

BSD Weekly.
https://bsdweekly.com/

DiscoverBSD.
https://discoverbsd.com/

BSDSec.
https://bsdsec.net/

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

BSDTV.
https://bsky.app/profile/bsdtv.bsky.social

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

BSDJedi.
https://youtube.com/@BSDJedi/videos

RoboNuggie.
https://youtube.com/@RoboNuggie/videos

GaryHTech.
https://youtube.com/@GaryHTech/videos

Sheridan Computers.
https://youtube.com/@sheridans/videos

82MHz.
https://82mhz.net/

EOF
Top

AMD Based FreeBSD Desktop Reloaded

Post by Vermaden via 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗 »

My previous AMD Based FreeBSD Desktop is still up and running – it will now be my kids computer … so I needed a new one … but not a bigger one 🙂 I spent way too much time finding new Mini-ITX case for the next one … and after all possibilities … I got Silverstone case again :] … because nothing else was this small and with all needed features. Also … I was thinking WHAT exactly should I buy – especially in the times with AI prices. For one of my older projects that failed (I hope to also publish about that some day) I had AMD Ryzen 4750GE CPU with 35W TDP but still 8C/16T CPU on AMD4 socket … so instead of killing all price/performance efficiency with DDR5 and AM5 setup … I went to decent AM4 option.

Case

Older build used Silverstone SG05 case and this one uses Silverstone SG13 … which is almost the same.

  WHAT     SG05     SG13
 Width    218mm    222mm
Height    175mm    181mm
 Depth    276mm    285mm
Volume    10.5L    10.8L

So one can say that its just a tiny 5% increase in size … but a welcome and needed one.

Difference

The new setup is about 25% faster when it comes to CPU and 40-60% faster in GPU department … depending on the workload. The SSD/NVMe speeds will be the same as its still the same AM4 platform … and RAM would also be similar as its again DDR4 sticks.

Assembly

After having the parts laying around for about a quarter (yes I was busy) my son finally forced me to make that build … and it was a positive push – we sit down in dining room with all needed parts and I started to assembly it with my son being more then curious how it is to actually build a computer.

First CPU into the motherboard … and NVME into the M.2 slot.

Next thermal paste and fan onto the CPU.

To be honest it was easier said then done as the Thermalight AXP-90 X47 comes with install options for both AMD and Intel solutions and it took me a little time to check all needed screws to use and their accessories.

Next – motherboard into the case.

Next RAM or GPU … as GPU was measured to fit within millimeters in that case I started with the GPU.

… and no matter how I tried … no matter which angles I tried to use … GPU would just not fit into the case 😦

I found funny that the GPU name was Challenger and it was REALLY challenging to fit it into the case.

I even decided to name that system challenger after that. I am a big fan of Dodge Challenger cars … I own a Dodge personally … just not a Challenger … yet 🙂

I inspected the GPU from every possible direction and one detail caught my attention …

The plastic cover with the fans was about 1cm wider then the PCB for the card … so I decided to cut it precisely at that place.

This is how the plastic cover looked like after being cut to the PCB length.

Here is how it went with the cutting – something like 2-3 minutes of work.

… and after reattaching the cover to the GPU card.

I went back to trying to fit the GPU into the case … but the cut was not enough … it would still not fit … so I changed strategy. I dissembled the expansion slot bracket from the GPU – out that expansion slot bracket into its place in the case – and tried to fit the card again – so later I can add screws to expansion slot bracket to attach it to GPU again … but I was not able to fit all those again. So next ‘victim’ of cutting was the expansion slot bracket … before on the picture below.

… and after 🙂

Not much was needed – but without that cut – fitting that Challenger into the case was not possible.

After that I was able to finally attach the GPU to the motherboard.

It was more or less like that.

… and after the additional bracket cover.

Next for the installation were RAM sticks and SSD SATA drive – nothing spectacular about that – after also adding the PSU it was more or less complete.

Its really nice that Thermaltake Toughpower Grand 750W PSU has detachable cables … so I could have one cable less in my case :] <sarcasm/>

I generally like to build … everything – that means also building computers … but one thing always pisses me off when I build a PC – the cables from the case buttons to motherboard.

Back in 2006 when I was building a gaming PC for my friend it looked more or less like that below – starting a PC with a screw 🙂

Difference

The difference in CPU power between older AMD Ryzen 7 1700 and AMD Ryzen 7 PRO 4750GE is about 25% percent. When it comes to GPU between 5700XT 8GB and 7700XT 12GB its somewhere between 40-60% percent.

There is almost zero ‘visual’ difference between the two – first the older one.

… and the newer one.

FreeBSD

The most important part of this article is sharing that all of these parts – especially GPU – works very well with FreeBSD with drm-kmod and x11-drivers/xlibre-xf86-video-amdgpu XLibre AMD Radeon GPU driver. After I learned how much some Red Hat people wanted to cripple and kill the X11 … I am not going back to Xorg X11 implementation … the XLibre X11 is my home … and do not even get me started on Wayland – the details about that topic are in the 200 MB RAM FreeBSD Desktop article.

Firmware

After install and reboot I started the fwget(8) command so that all needed firmware for FreeBSD will be fetched.

challenger # fwget -v
Trying to match device 0x747e in class video and vendor amd with pci_video_amd
Trying to match device 0x8168 in class network and vendor realtek with pci_network_realtek
Trying to match device 0x24fb in class network and vendor intel with pci_network_intel
Needed firmware packages: 'wifi-firmware-iwlwifi-kmod-7000'                                                    

But as it seams it was not enough as I got these boot errors on every FreeBSD system start.

iwmbtfw: iwmbt_fw_read: open: /usr/local/share/iwmbt-firmware/ibt-hw-37.8.bseq: No such file or directory
iwmbtfw: main: Firmware download failed!                      

… so I start to dig where the problem is. For a start I checked all /etc/rc.d services for iwmbtfw name.

challenger # grep -r iwmbtfw /etc
/etc/devd/iwmbtfw.conf: action "/usr/sbin/iwmbtfw -d $cdev -f /usr/local/share/iwmbt-firmware";

challenger # ls /usr/local/share/iwmbt-firmware
ls: /usr/local/share/iwmbt-firmware: No such file or directory

So the /usr/local/share/iwmbt-firmware seems to be missing but its suppose to be there …

challenger # man iwmbtfw | grep firmware
     Firmware files are available in the comms/iwmbt-firmware port.

OK … lets install the comms/iwmbt-firmware package.

challenger # pkg search -o iwmbt
comms/iwmbt-firmware           Intel Wireless bluetooth adaptor firmwares used by iwmbtfw(8)

challenger # pkg install iwmbt-firmware
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        iwmbt-firmware: 20251111 [FreeBSD-ports]

Number of packages to be installed: 1

The process will require 15 MiB more space.
5 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching iwmbt-firmware-20251111: 100%  4840 KiB 619.5 kB/s    00:08
Checking integrity... done (0 conflicting)
[1/1] Installing iwmbt-firmware-20251111...
[1/1] Extracting iwmbt-firmware-20251111: 100%

After reboot I never saw that error message again – so that is the needed fix.

Hardware

This is the exact hardware I got with the prices I paid for it in EUR currency. Some were bought as new and some as used.

 TYPE  EUR  WHAT                                    
 CASE   55  Silverstone SG13
  PSU   55  Thermaltake Toughpower Grand 750W
 MOBO  100  ASRock B550M-ITX/ac
  CPU  145  AMD Ryzen 7 4750GE 8C/16T 35W TDP
  GPU  340  ASRock ATI Radeon 7700XT 12GB Challenger
PASTE   10  Grizzly Thermal Kryonaut 2g
 COOL   40  Thermalight AXP-90 X47
  FAN    5  Savio BLADEX1 120mm PWM
  SSD   45  ADATA SU650 512GB
 NVME   50  Phison ESO512GYLCT-EP3-2L 512GB
  RAM  150  2 x 16GB Goodram DDR4 3600MHz 1.35V CL18
PRICE  995  TOTAL

Not sure it was worth it but I did it anyway.

In the mean time I also upgraded my older HP E221c FullHD monitor for HP E271i FullHD one … with additional HP soundbar mounted below the screen. To be honest – nothing fancy about that – the monitor was about 70 EUR and about 15 EUR for the soundbar.

XLibre X11

I installed these packages.

challenger # \
  pkg install -y \
    drm-kmod \
    xlibre \
    openbox \
    xterm \
    xinit \
    mesa-demos \
    scrot \
    radeontop \
    screen \
    lsblk \
    beadm \
    smartmontools

Next I started the XLibre X11 as usual.

vermaden@challenger % echo openbox > ~/.xinitrc

vermaden@challenger % xinit -- -dpi 75 -nolisten tcp

… and the X11 XLibre display server started as usual – but after I checked the logs … I was using the software scfb driver … and I was not in the video group – so I added myself there.

challenger # pw groupmod video -m vermaden

Next … I searched for amdgpu driver …

challenger # pkg search -o amdgpu
x11-drivers/xf86-video-amdgpu         X.Org amdgpu display driver
x11-drivers/xlibre-xf86-video-amdgpu  XLibre amdgpu display driver

Its important to install the x11-drivers/xlibre-xf86-video-amdgpu one because the other one will force You to uninstall XLibre and install Xorg.

Next I added the AMD Radeon X11 config.

challenger # cat /usr/local/etc/X11/xorg.conf.d/card.conf 
Section "Device"
  Identifier "Card0"
  Driver "amdgpu"
  Option "TearFree" "true"
EndSection

Nothing fancy but works as desired.

I also checked the /var/log/Xorg.0.log for details and …

[2026-09-05 14:48:22] (II) LoadModule: "amdgpu"
[2026-09-05 14:48:22] (II) Loading /usr/local/lib/xorg/modules/xlibre-25/drivers/amdgpu_drv.so
[2026-09-05 14:48:22] (II) Module amdgpu: vendor="X.Org Foundation"
[2026-09-05 14:48:22]   compiled for 1.25.1.9, module version = 25.1.2
[2026-09-05 14:48:22]   Module class: X.Org Video Driver
[2026-09-05 14:48:22]   ABI class: X.Org Video Driver, version 28.1
[2026-09-05 14:48:22] (II) AMDGPU: Driver for AMD Radeon:
        All GPUs supported by the amdgpu kernel driver

Yep … this is what we wanted.

This is how that GPU looks like in the pciconf(8) output.

challenger # pciconf -lv vgapci0
vgapci0@pci0:3:0:0:     class=0x030000 rev=0xff hdr=0x00 vendor=0x1002 device=0x747e subvendor=0x1849 subdevice=0x5323
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Navi 32 [Radeon RX 7700 XT / 7800 XT]'
    class      = display
    subclass   = VGA

This is how resources usage looks like in X11 XLibre session on FreeBSD.


challenger # top -b -ores
last pid:  5702;  load averages:    0.08,    0.08,    0.02  up 0+00:30:16    14:35:51
34 processes:  1 running, 33 sleeping
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.9% idle
Mem: 92M Active, 101M Inact, 1512M Wired, 2056K Buf, 29G Free
ARC: 141M Total, 24M MFU, 113M MRU, 388K Anon, 670K Header, 2159K Other
     88M Compressed, 207M Uncompressed, 2.35:1 Ratio
Swap: 4096M Total, 4096M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
90382 vermaden     16   0    0   319M   136M select   6   0:01   0.00% Xorg
92537 vermaden      2   0    0    50M    22M select  12   0:00   0.00% openbox
 1117 vermaden      1   0    0    26M    14M select  13   0:00   0.00% xterm
77479 root          1   0    0    25M    10M select  14   0:00   0.00% sshd
17882 root          1   0    0    15M  4356K select   9   0:00   0.00% devd
89878 vermaden      1   1    0    16M  3808K wait     5   0:00   0.00% xinit
 2151 vermaden      1   0    0    14M  3500K wait     2   0:00   0.00% sh
 5702 root          1   0    0    15M  3492K CPU9     9   0:00   0.00% top
 1924 root          1   0    0    14M  3280K wait     4   0:00   0.00% login

This is how the main FreeBSD /etc/rc.conf config looks like.

challenger # cat /etc/rc.conf
  hostname="challenger.local"
  ifconfig_re0="inet 10.0.0.5/24 up"
  defaultrouter="10.0.0.1"

  kld_list="${kld_list} amdgpu amdtemp"
  syslogd_flags="-ss"
  sshd_enable="YES"
  powerd_enable="YES"
  dumpdev="AUTO"
  zfs_enable="YES"

Far from fancy – just simple stuff.

Power

Power measurement seems similar to older model – but slightly smaller.

POWER  STATE                                     
  47W  IDLE without amdgpu.ko loaded
  39W  IDLE with amdgpu.ko loaded
  45W  BUSY with 16 x 100% CPU Thread(s) @ 1.4GHz
  80W  BUSY with 16 x 100% CPU Thread(s) @ 3.1GHz

The Turbo frequency for the AMD Ryzen 7 4750GE CPU is at 4.3GHz … but I am not sure its used … because for example a CPU in my laptop has two ‘final’ speeds shown as 1801/15000 1800/15000 and the one with additional 1 it the one with Turbo mode … but nothing like that for that AMD Ryzen 7 4750GE CPU.

Also … there is only C1 state supported … which is sad 😦

challenger # sysctl dev.cpu.0
dev.cpu.0.temperature: 47.0C
dev.cpu.0.cx_method: C1/hlt
dev.cpu.0.cx_usage_counters: 259234
dev.cpu.0.cx_usage: 100.00% last 19092us
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_supported: C1/1/0
dev.cpu.0.freq_levels: 3100/3778 1700/1615 1400/1277
dev.cpu.0.freq: 1400
dev.cpu.0.%iommu: 
dev.cpu.0.%parent: acpi0
dev.cpu.0.%pnpinfo: _HID=ACPI0007 _UID=0 _CID=none
dev.cpu.0.%location: handle=\_SB_.PLTF.C000
dev.cpu.0.%driver: cpu
dev.cpu.0.%desc: ACPI CPU

This is how the sensors(8) output looks like on that box.

challenger # sensors

            BATTERY/AC/TIME/FAN/SPEED 
 ------------------------------------ 
               dev.cpu.0.cx_supported: C1/1/0 
                   dev.cpu.0.cx_usage: 100.00% last 10882us
                       dev.cpu.0.freq: 1400 
                hw.acpi.cpu.cx_lowest: C1 
                            powerd(8): running

                  SYSTEM/TEMPERATURES 
 ------------------------------------ 
                dev.cpu.0.temperature: 47.1C
                dev.cpu.1.temperature: 47.1C
                dev.cpu.2.temperature: 47.1C
                dev.cpu.3.temperature: 47.1C
                dev.cpu.4.temperature: 47.1C
                dev.cpu.5.temperature: 47.1C
                dev.cpu.6.temperature: 47.1C
                dev.cpu.7.temperature: 47.1C
                dev.cpu.8.temperature: 47.1C
                dev.cpu.9.temperature: 47.1C
               dev.cpu.10.temperature: 47.1C
               dev.cpu.11.temperature: 47.1C
               dev.cpu.12.temperature: 47.1C
               dev.cpu.13.temperature: 47.1C
               dev.cpu.14.temperature: 47.1C
               dev.cpu.15.temperature: 47.1C

                   DISKS/TEMPERATURES 
 ------------------------------------ 
       smart.ada0.temperature_celsius: 34.0C
              smart.nvme0.temperature: 39.0C

Not great. Not terrible.

PKGBASE Upgrade

As I installed stock 15.1-RELEASE I will now upgrade to latest 15.1-pX release available.

challenger # pkg upgrade -r FreeBSD-base
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
FreeBSD-base is up to date.
Checking for upgrades (53 candidates): 100%
Processing candidates (53 candidates): 100%
The following 52 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        FreeBSD-audit: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-autofs: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-bhyve: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-bsnmp: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-clang: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-clang-dev: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-clibs: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-clibs-dev: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-clibs-dev-lib32: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-clibs-lib32: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-console-tools: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-ctl: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-jail: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-kernel-generic: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-kernel-generic-dbg: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-lib9p: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-lib9p-dev: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-lib9p-dev-lib32: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-lib9p-lib32: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-libevent1: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-libevent1-dev: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-libevent1-dev-lib32: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-libevent1-lib32: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-mtree: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-natd: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-natd-dev: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-natd-dev-lib32: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-natd-lib32: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-ntp: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-openssl-dev: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-openssl-dev-lib32: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-openssl-lib: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-openssl-lib32: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-pmc: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-ppp: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-rescue: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-runtime: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-runtime-dev: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-runtime-dev-lib32: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-runtime-lib32: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-src: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-src-sys: 15.1 -> 15.1p3 [FreeBSD-base]
        FreeBSD-syslogd: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-utilities: 15.1 -> 15.1p2 [FreeBSD-base]
        FreeBSD-utilities-dev: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-utilities-dev-lib32: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-utilities-lib32: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-zfs-dev: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-zfs-dev-lib32: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-zfs-lib: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-zfs-lib32: 15.1 -> 15.1p1 [FreeBSD-base]
        FreeBSD-zoneinfo: 15.1 -> 15.1p2 [FreeBSD-base]

Number of packages to be upgraded: 52

579 MiB to be downloaded.

Proceed with this action? [y/N]: y

… and it all went well. After the upgrade finished I rebooted and everything worked like a charm.

Offtopic

Fast forward half a year later after the build happened in that dining room – my 10 years old son comes to me a month ago and says ‘Hey dad I just wrote this PC Builder game with ChatGPT do You want to play it?’ … and after I checked it I was really shocked … positively. I mean … when I was 10 years old I did not even had my AMIGA 600 … I was playing various games on Pegasus – which is a cheap Polish NES clone … I would get AMIGA 600 when I was more or less like 12 years old (speaking from foggy memories) … and I was still playing games like Sensible World od Soccer or Cannon Fodder instead of creating anything. This is how this (after many iterations with AI) PC Builder game looks like.

Yes – its in Polish – but I believe its just one prompt away from making it English/Polish when needed 🙂

My son also surprised me because one of the times I told him that ‘its not only ChatGPT out there – there are others like Perplexity or Claude or Gemini or … and several times he said ‘Dad I run out of tokens and just copied that I had and put that into other AI and it picked up my work and added the changes I wanted …’ – when I look at my son doing this stuff – being literally a Vibe Coder (still at the beginning of his route but still) … I feel like the schooling system is just one big fucking joke … I mean Mathematics/Physics/English/… are needed and useful … bot others? Optional to say the least … and I felt (and act accordingly) when I was in the school. Its just such a fucking waste of time to cram for some exam and forgot all that shit to get a grade.

What I find funny is that my son never played a game I wrote … and I already played two games of his … I wish every parent to have the same.

EOF
Top

Valuable News – 2026/08/31

Post by Vermaden via 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗 »

The Valuable News weekly series is dedicated to provide summary about news, articles and other interesting stuff mostly but not always related to the UNIX/BSD/Linux systems. Whenever I stumble upon something worth mentioning on the Internet I just put it here.

Today the amount information that we get using various information streams is at massive overload. Thus one needs to focus only on what is important without the need to grep(1) the Internet everyday. Hence the idea of providing such information ‘bulk’ as I already do that grep(1).

The Usual Suspects section at the end is permanent and have links to other sites with interesting UNIX/BSD/Linux news.

Past releases are available at the dedicated NEWS page.

UNIX

Bhyve Inside Jail: FreeBSD Feature Nobody Uses.
https://blog.hofstede.it/bhyve-inside-a-jail-the-freebsd-feature-nobody-uses/

FreeBSD 14.5-RC1 Now Available.
https://lists.freebsd.org/archives/freebsd-stable/2026-August/004288.html

FreeBSD 14.5-RC1 Released with Several Security Fixes.
https://phoronix.com/news/FreeBSD-14.5-RC1

Why is This Running witr(1) Tool to Trace any Process/Port/Container/File.
https://github.com/pranshuparmar/witr

GSoC 2026 Reports: Improving RAIDframe on NetBSD.
https://blog.netbsd.org/tnf/entry/gsoc2026_raidframe

Install Void Linux with ZFS Boot Environments/Hibernation/Encryption.
https://it-notes.dragas.net/2025/12/22/void-linux-zfs-hibernation-guide/

VirtIO GPU QEMU/UTM Display Driver for FreeBSD Guests so Xorg/Xlibre Use xf86-video-scfb Dirver.
https://gitlab.com/tgasiba/virtio_gpu_qemu

Powercool 1000VA and 850VA UPS on FreeBSD with NUT.
https://forums.sheridancomputers.com/t/powercool-1000va-and-850va-ups-on-freebsd-with-nut/185

New FreeBSD Compatible wifi-tui Tool to Scan/Conenct/Manage WiFi Networks.
https://github.com/hirechbaghdad/wifi-tui/

GParted or Partition Manager for FreeBSD.
https://forums.freebsd.org/threads/gparted-partition-manager.103693/

There is No Linux Admin.
https://vivianvoss.net/blog/no-linux-admin

FreeBSD facl(8) Tool to Manage NFSv4 ACLs.
https://github.com/olgeni/facl

FreeBSD zfs-allow(8) Tool to Manage ZFS Delegated Administration.
https://github.com/olgeni/zfs-allow

FreeBSD zfs-set(8) Tool to Manage ZFS Dataset Properties.
https://github.com/olgeni/zfs-set

FreeBSD zpool-set(8) Tool to Manage ZFS Pool Properties.
https://github.com/olgeni/zpool-set

Hardware Acceleration on FreeBSD 14.4 i386.
https://reddit.com/r/freebsd/comments/1vyez95/hardware_acceleration_on_freebsd_144_i386/

Run OpenBSD on DigitalOcean for $4 per Month.
https://nil.wallyjones.com/run-openbsd-on-digitalocean-for-4month/

What Happens When You Connect to Starbucks WiFi.
https://nil.wallyjones.com/what-happens-when-you-connect-to-starbucks-wi-fi/

Sylve 0.3.0 Released.
https://github.com/AlchemillaHQ/Sylve/releases/tag/v0.3.0

What Shell am I Using?
https://nil.wallyjones.com/what-shell-am-i-using/

FreeBSD Foundation Intern Jim Huang Chen on Raspberry Pi Support and Open Source.
https://freebsdfoundation.org/blog/freebsd-foundation-intern-jim-huang-chen-on-raspberry-pi-support-and-open-source/

Sylve – Modern Virtualization Solution.
https://tomsitcafe.com/2026/07/24/sylve-a-modern-virtualization-solution/

Postgres pgbot(1) Intelligence for AI Agents and Apps.
https://github.com/pgrundev/pgbot

Lenovo XClarity Administrator in FreeBSD Bhyve VM.
https://vermaden.wordpress.com/2026/08/28/lenovo-xclarity-administrator-in-freebsd-bhyve-vm/

BSDnas is Community Fork that Continues TrueNAS CORE on Current FreeBSD.
https://bsdnas.com/

WebZFS is Modern Web Interface for ZFS Administration.
https://webzfs.com/

FreeCORE Descends from FreeNAS/TrueNAS CORE and Builds on FreeBSD and OpenZFS.
https://freecore.org/

Challenges in Bringing AMD ROCm to FreeBSD.
https://phoronix.com/news/AMD-ROCm-FreeBSD-Intern-Report

f3s: Kubernetes with FreeBSD – Part 10 – New Home.
https://foo.zone/gemfeed/2026-09-01-f3s-kubernetes-with-freebsd-part-10.html

Sandbox Inside the Jail.
https://vivianvoss.net/blog/sandbox-inside-the-jail

What Isolation Actually Costs.
https://vivianvoss.net/blog/isolation-costs

BSD Weekly – Issue 293.
https://bsdweekly.com/issues/293

Enabling TRIM on LUKS Encrypted SSD on Linux.
https://forums.sheridancomputers.com/t/enabling-trim-on-a-luks-encrypted-ssd-on-arch-linux/186

UNIX/Audio/Video

BSD Now 678: Ceiling Cat Has Another Meaning.
https://www.bsdnow.tv/678

Hardware

PINE64 Partially Halts Production Due to Memory Shortage.
https://heise.de/en/news/PINE64-partially-halts-production-due-to-memory-shortage-11423218.html

Commodore 77.
https://commodore.net/store/commodore64/

MNT Station Modular and Open Hardware Desktop/Server Computer.
https://crowdsupply.com/mnt-research/mnt-station

Motorola GrapheneOS Phones Will Launch in 2027 Pricier than Pixels
https://arstechnica.com/gadgets/2026/08/motorolas-grapheneos-phones-will-launch-in-2027-priced-higher-than-pixels/

Samsung New P9 USB4 SSD Promises 4000MB/s.
https://dpreview.com/news/step-aside-t9-samsungs-new-p9-usb4-drive-delivers-4-000mb-s-for-photo-workflows/

Life

How Much of Internet is Written With AI?
https://pewresearch.org/data-labs/2026/08/20/how-much-of-the-internet-is-written-with-ai/

Meet Eliza Zhang – Book Scanner at Internet Archive.
https://blog.archive.org/2021/02/09/meet-eliza-zhang-book-scanner-and-viral-video-star/

Temperature Zero for Culture: Why Everything is Starting to Look the Same.
https://laurenleek.substack.com/p/temperature-zero-for-culture-why

Other

Heroes ]|[ Remake – Gameplay Overview Trailer with Commentary.
https://youtube.com/watch?v=i9RahV1tj50

ReactOS 0.4.16 Released with New Graphical Installer and Better Hardware Support.
https://phoronix.com/news/ReactOS-0.4.16-Released

Aptivi Weekly Tech News 2026/08/29.
https://officialaptivi.wordpress.com/2026/08/29/aptivi-weekly-tech-news-issue-13-week-35-8-29-2026/

Lazy Reading for 2026/08/30.
https://dragonflydigest.com/2026/08/30/lazy-reading-for-2026-08-30/

Making My Dream City Builder – Part 1 – Parcels.
https://youtube.com/watch?v=4heM4MqK82w

Making My Dream City Builder – Part 2 – Traffic.
https://www.youtube.com/watch?v=BoqK5wOGpfU

Making My Dream City Builder – Part 3 – City Simulation.
https://www.youtube.com/watch?v=2NvNp9QXMCM

Usual Suspects

BSD Weekly.
https://bsdweekly.com/

DiscoverBSD.
https://discoverbsd.com/

BSDSec.
https://bsdsec.net/

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

BSDTV.
https://bsky.app/profile/bsdtv.bsky.social

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

BSDJedi.
https://youtube.com/@BSDJedi/videos

RoboNuggie.
https://youtube.com/@RoboNuggie/videos

GaryHTech.
https://youtube.com/@GaryHTech/videos

Sheridan Computers.
https://youtube.com/@sheridans/videos

82MHz.
https://82mhz.net/

EOF
Top

Expat 2.8.4 released, fixes 4 vulnerabilities

Post by Sebastian Pipping via Hartwork Blog »

For readers new to Expat:

libexpat is a fast streaming XML parser. Alongside libxml2, Expat is one of the most widely used software libre XML parsers written in C, specifically C99. It is cross-platform and licensed under the MIT license.

Expat 2.8.4 was released a few hours ago. The key motivation for cutting a release and doing so now was getting the fixes to four vulnerabilities…

…into the hands of the community.

The vulnerabilities were reported by Darren Carreras, Fabian Wahle (Hap Security), Sorrashut Kaewtaworn, Zeyou Liu, and the fixing was done by Darren Carreras, Sorrashut Kaewtaworn, Zeyou Liu, and me — thank you!

Issue CVE-2026-66046 is worth illustrating, and the fixing pull request contains an attack payload generator in its description. The issue was that if an attacker dials up a document like…

<!DOCTYPE e [
  <!ATTLIST e a0 NMTOKEN "x">
  <!ATTLIST e a1 NMTOKEN "x">
  <!ATTLIST e a2 NMTOKEN "x">
]>
<e a0=" v " a1=" v " a2=" v " />

…from 3 attributes to thousands, they could leverage the now-past quadratic runtime nature of Expat's related machinery to cause denial of service even with moderatly sized payload. The fix was migrating from an O(n) loop to an amortized O(1) hash table lookup.

As usual, there is also non-security work that went into this release. For instance, on the infrastructure side of things, the CI now covers Fil-C, RISC-V, Clang-based MinGW, and (the big-endian architecture) s390x for the first time.

It should be noted that it was the Open Source Sabbatical of the City of Munich that allowed me to focus on libexpat for the community through its funding — thank you! This has been the first month, and there are hopefully five more to come; there continues to be plenty to do. Wish me luck!

Thanks to everyone who contributed to this release of Expat!

For more details about this release, please check out the change log.

If you maintain Expat packaging, a bundled copy of Expat, or a pinned version of Expat, please update to version 2.8.4. Thank you!

Sebastian Pipping

Top

Lenovo XClarity Administrator in FreeBSD Bhyve VM

Post by Vermaden via 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗 »

This is another entry that is sponsored by fme AG company. If You have multiple Lenovo ThinkServer systems to manage You may do that by hand with entering UEFI/BIOS setup and doing needed things by hand … or You can setup a Lenovo XClarity Administrator VM.

The problem is that this VM from Lenovo comes by default in three versions … and none of them is by default suited for FreeBSD Bhyve hypervisor.

  • VHD for Windows Hyper-V hypervisor.
  • OVA for VirtualBox and others that support OVA format.
  • QCOW2 for Linux KVM based hypervisors.

As usual I decided not to give up at that point and tried harder … and that trying led me to some interesting conclusions.

I downloaded the QCOW2 version listed as lnvgy_sw_lxca_120-4.3.0_kvm_x86-64.qcow2 file – its about 3.2 GB in size.

Then I created the Bhyve VM for that Linux system.

freebsd # vm create lxca 

As I had the Lenovo image in QCOW2 format I used qemu-img(1) from the emulators/qemu package to convert it to RAW format that is suitable for FreeBSD Bhyve hypervisor. One important thing to note before doing the conversion … the size of RAW disk will be 192 GB. It will not matter on ZFS with compression enabled – but it can fill Your disk if You have compression disabled.

freebsd # zfs get -d 0 compression
NAME   PROPERTY     VALUE           SOURCE
zroot  compression  lz4             local

freebsd # du -smh \
            lnvgy_sw_lxca_120-4.3.0_kvm_x86-64.qcow2 \
            /vm/lxca/disk0.img 
3.2G    lnvgy_sw_lxca_120-4.3.0_kvm_x86-64.qcow2
4.6G    /vm/lxca/disk0.img

freebsd # du -smhA \
              lnvgy_sw_lxca_120-4.3.0_kvm_x86-64.qcow2 \
              /vm/lxca/disk0.img
3.2G    lnvgy_sw_lxca_120-4.3.0_kvm_x86-64.qcow2
192G    /vm/lxca/disk0.img

Now the conversion.

freebsd # pkg which -o $( which qemu-img )
/usr/local/bin/qemu-img was installed by package emulators/qemu

freebsd # \
  qemu-img convert -f qcow2 -O raw \
    lnvgy_sw_lxca_120-4.3.0_kvm_x86-64.qcow2 \
    /vm/lxca/disk0.img

I then investigated what actually is on that raw disk and FreeBSD md(4) driver helped here beautifully. We will also use my mdconfig.sh script to make it easier.

freebsd # mdconfig.sh -c disk0.img
IN: created vnode at /dev/md0

freebsd # lsblk md0
DEVICE         MAJ:MIN  SIZE TYPE                                    LABEL MOUNT
md0              1:183  192G MBR                                         - -
  <FREE>         -:-    993K -                                           - -
  md0s1          1:184   24G linux-data                         ext2fs/ELR -
  md0s2          1:205    8G linux-data                 ext2fs/ELR_VAR_LOG -
  md0s3          1:206  160G linux-data               ext2fs/ELR_LXCA_DATA -

So … now we know that its an MBR partitioning scheme … which means UEFI boot is not possible – and this is where it gets ugly because Bhyve is not VirtualBox (and I admit this is one of the Bhyve downsides) which means we now have to find needed parameters for Bhyve to boot that Linux VM.

We can at least mount these partitions to check what is in them … and also check the GRUB config. We will use lklfuse(8) from the filesystems/lkl package for that – lets try with the 1st partition.

freebsd # pkg which -o $( which lklfuse ) 
/usr/local/bin/lklfuse was installed by package filesystems/lkl

freebsd # mkdir -p /mnt/tmp

freebsd # lklfuse -o type=ext4 /dev/md0s1 /mnt/tmp

freebsd # ls -l /mnt/tmp
total 76
drwxr-xr-x   2 root wheel     4096 Feb 19  2025 bin
drwxr-xr-x   3 root wheel     4096 Apr  9  2025 boot
lrwxrwxrwx   1 root wheel       28 Jun  6  2025 chroot -> /opt/lenovo/lxca/data/chroot
drwxr-xr-x   2 root wheel     4096 Feb 19  2025 dev
lrwxrwxrwx   1 800  800         26 Jun  6  2025 dump -> /opt/lenovo/lxca/data/dump
drwxr-xr-x  66 root wheel     4096 Aug 28 00:40 etc
drwxr-xr-x  12 root wheel     4096 Aug 28 00:40 home
drwxr-xr-x   8 root wheel     4096 Feb 19  2025 lib
lrwxrwxrwx   1 root wheel        3 Jun  6  2025 lib64 -> lib
drwx------   2 root wheel    16384 Jun  6  2025 lost+found
drwxr-xr-x   2 root wheel     4096 Feb 19  2025 media
drwxrwxr-x   2 root wheel     4096 Feb 19  2025 mnt
drwxr-xr-x   7 root wheel     4096 Jun  6  2025 opt
dr-xr-xr-x   2 root wheel     4096 Feb 19  2025 proc
drwxr-xr-x  10 root wheel     4096 Jun  6  2025 run
drwxr-xr-x   2 root wheel     4096 Feb 19  2025 sbin
dr-xr-xr-x   2 root wheel     4096 Feb 19  2025 sys
lrwxrwxrwx   1 root wheel        8 Jun  6  2025 tmp -> /var/tmp
drwxr-xr-x  11 root wheel     4096 Feb 19  2025 usr
drwxr-xr-x  11 root wheel     4096 Jun  6  2025 var

freebsd # ls -l /mnt/tmp/boot
total 14176
lrwxrwxrwx   1 root wheel       16 Jun  6  2025 bzImage -> bzImage-5.15.178
-rw-r--r--   1 root wheel 11837760 Feb 19  2025 bzImage-5.15.178
drwxr-xr-x   2 root wheel     4096 Jun  6  2025 grub
-rw-r--r--   1 root wheel  2670312 Feb 19  2025 initrd
freebsd # cat /mnt/tmp/boot/grub/grub.conf
default=0
timeout=1

title System Management Platform
        root (hd0,0)
        kernel /boot/bzImage ro console=tty0 console=ttyS0 root=LABEL=ELR clocksource_failover=acpi_pm net.ifnames=0 clocksource_failover=acpi_pm
        initrd /boot/initrd

freebsd # cd /

freebsd # umount /mnt/tmp

freebsd # mdconfig.sh -d 0
IN: deleted vnode at /dev/md0

So … we know what the GRUB config looks like – lets try to translate that into FreeBSD Bhyve VM config. After playing some time I settled on this lxca VM config as shown below.

freebsd # env EDITOR=cat vm config lxca
loader="grub"
grub_run_partition="msdos1"
grub_run_dir="/boot/grub"
grub_run0="linux /boot/bzImage ro console=tty0 console=ttyS0 root=LABEL=ELR clocksource_failover=acpi_pm net.ifnames=0 clocksource_failover=acpi_pm"
grub_run1="initrd /boot/initrd"
cpu=3
memory=16G
network0_type="e1000"
network0_switch="public"
network0_mac="58:9c:fc:06:2e:71"
network1_type="e1000"
network1_switch="public"
network1_mac="58:9c:fc:02:3b:c0"
disk0_type="virtio-blk"
disk0_name="disk0.img"
uuid="53211072-22f1-43f0-97c4-fae86903b2fc"

Then we need to start the VM with usual command.

freebsd # vm start lxca

You may (and should) trace the boot process with vm console {VM} command of course.

freebsd # vm console lxca

You will see lots of Linux boot messages both first from the Linux kernel itself and later from the booting process of applications/daemons/databases needed to start Lenovo XClarity Administrator appliance. After some time – definitely longer then shorter – You will see something like that below.

**************************************************************
 This interface is not for user or customer usage    *********
**************************************************************


------------------------------------------
Lenovo LXCA - Version 4.3.0 build 120
------------------------------------------

eth0: flags=4163  mtu 1500
        inet 10.1.1.52  netmask 255.255.255.0  broadcast 10.1.1.255
        inet6 fe80::5a9c:fcff:fe06:2e71  prefixlen 64  scopeid 0x20
        ether 58:9c:fc:06:2e:71  txqueuelen 1000  (Ethernet)
        RX errors 0  dropped 0  overruns 0  frame 0

eth1:      Disabled

localhost login: 

This means that You can how try to access https://10.1.1.52/ in Your browser … and after I tried that I (of course) needed to accept the self generated certificate and then I saw this.

Voila! It works! 🙂

Now You can configure it from the browser as needed.

Guide that really helped me to setup all these things right was the Lenovo XClarity Administrator – Users Guide that has this in its contents.

It shows TWO network interfaces here – eth0 and eth1 – not just one – and when I used only one – everything failed – after I added 2nd network interface – everything started to work as desired.

I do not have anything more to add here – I am really glad that I persisted hard to try all available options here – take care 🙂

UPDATE 1 – Lenovo XClarity One

Graham Perrin commented on one of the places where I shared the article that XClarity Administrator will not be supported after 2027/06/30 and that XClarity One is now the future … so I tried to setup XClarity One under FreeBSD Bhyve VM and this update will show You the details.

 

The Lenovo XClarity One can be downloaded as QCOW2 image here – so I did. Now it seams that there are TWO disks instead of just ONE – but that does not bring any problems for Bhyve – we will attach them both.

freebsd # vm create lxco

freebsd # cd /vm/lxco

freebsd # du -smh ~/lnvgy_sw_xc1_26p.2.0_kvm_indiv.tgz                       
5.0G    /home/vermaden/lnvgy_sw_xc1_26p.2.0_kvm_indiv.tgz

freebsd # du -smhA ~/lnvgy_sw_xc1_26p.2.0_kvm_indiv.tgz
5.0G    /home/vermaden/lnvgy_sw_xc1_26p.2.0_kvm_indiv.tgz

freebsd # tar -xvf ~/lnvgy_sw_xc1_26p.2.0_kvm_indiv.tgz 
x ./lnvgy_sw_xc1_7909-uat_kvm_x86_64_disk1.qcow2
x ./lnvgy_sw_xc1_7909-uat_kvm_x86_64_disk2.qcow2

freebsd # qemu-img convert -f qcow2 -O raw lnvgy_sw_xc1_7909-uat_kvm_x86_64_disk1.qcow2 disk0.img

freebsd # qemu-img convert -f qcow2 -O raw lnvgy_sw_xc1_7909-uat_kvm_x86_64_disk2.qcow2 disk1.img

freebsd # ls -l /vm/lxco
total 13534815
-rw-r--r--  1 root wheel 257699151872 Aug 28 21:27 disk0.img
-rw-r--r--  1 root wheel 536870912000 Aug 28 21:25 disk1.img
-rw-r--r--  1 root wheel  16380461056 Jul 16 13:58 lnvgy_sw_xc1_7909-uat_kvm_x86_64_disk1.qcow2
-rw-r--r--  1 root wheel       204608 Jul 16 13:58 lnvgy_sw_xc1_7909-uat_kvm_x86_64_disk2.qcow2
-rw-r--r--  1 root wheel          213 Aug 28 21:18 lxco.conf
-rw-r--r--  1 root wheel           66 Aug 28 21:18 vm-bhyve.log

freebsd # ls -lh /vm/lxco
total 13534815
-rw-r--r--  1 root wheel 240G Aug 28 21:27 disk0.img
-rw-r--r--  1 root wheel 500G Aug 28 21:25 disk1.img
-rw-r--r--  1 root wheel  15G Jul 16 13:58 lnvgy_sw_xc1_7909-uat_kvm_x86_64_disk1.qcow2
-rw-r--r--  1 root wheel 200K Jul 16 13:58 lnvgy_sw_xc1_7909-uat_kvm_x86_64_disk2.qcow2
-rw-r--r--  1 root wheel 213B Aug 28 21:18 lxco.conf
-rw-r--r--  1 root wheel  66B Aug 28 21:18 vm-bhyve.log

I believe at least some things could have change – so lets have a look inside 🙂

freebsd # mdconfig.sh -c disk0.img
IN: created vnode at /dev/md0

freebsd # lsblk md0
DEVICE         MAJ:MIN  SIZE TYPE                                    LABEL MOUNT
md0              1:182  240G MBR                                         - -
           -:-    993K -                                           - -
  md0s1          1:183    2G linux-data                     gpt/linux-data -
  md0s2          1:184   20G linux-data                     gpt/linux-data -
  md0s3          1:206   20G linux-data                     gpt/linux-data -
  md0s4          2:7    198G EBR                                   gpt/ebr -
    md0s4+00000001   2:9     99G linux-data                                  - -
    md0s4+03295525   2:11    99G linux-data                                  - -
           -:-     62K -                                           - -

freebsd # lklfuse -o type=ext4 /dev/md0s1 /mnt/tmp

freebsd # ls -l /mnt/tmp
total 16400
-rw-r--r--  1 root wheel 16749568 Oct  9  2025 bzImage
drwxr-xr-x  3 root wheel     4096 Oct  9  2025 grub
drwx------  2 root wheel    16384 Oct  9  2025 lost+found

freebsd # ls -l /mnt/tmp/grub
total 16
-rw-r--r--  1 root wheel   129 Oct  9  2025 grub.cfg
drwxr-xr-x  2 root wheel 12288 Oct  9  2025 i386-pc

freebsd # cat /mnt/tmp/grub/grub.cfg
set timeout=10
  menuentry 'XClarity Portal' {
  linux /bzImage root=PARTUUID=f869306a-02 rw net.ifnames=0 loglevel=4 console=tty1
}

So … no more initrd and different linux line … not much. This is how the new vm-bhyve config looks like.

freebsd # cat /vm/lxco/lxco.conf
loader="grub"
grub_run_dir="/grub"
grub_run_partition="msdos1"
grub_run0="linux /bzImage root=PARTUUID=f869306a-02 rw net.ifnames=0 loglevel=4 console=tty1"
cpu=8
memory=16G
network0_type="e1000"
network0_switch="public"
network0_mac="58:9c:fc:0a:cf:eb"
network1_type="e1000"
network1_switch="public"
network1_mac="58:9c:fc:03:25:d7"
disk0_type="virtio-blk"
disk0_name="disk0.img"
disk1_type="virtio-blk"
disk1_name="disk1.img"
uuid="d2eb04ed-1884-45c8-987f-f5df7e412664"

Lets start this thing.

freebsd # vm start lxco

freebsd # vm console lxco

Seems to boot without errors – this is what is visible on the console.

(...)

        Welcome to XClarity One Portal 26p.2.0-7909

VM Information:
---------------
-                IPv4: 
-             Netmask: 0.0.0.0
-             Gateway: 
-        Internal CNI: 192.168.255.0/25
-                UUID: 89705D12214F40249DB75E00D2D1C522
System Information:
-------------------
-         CPU # Cores: 8
-     CPU Utilization: 28.83 %
-  Memory Utilization: 2.31 % (370 MB of 15999 MB)
- Storage Utilization: 47.25 % (113.41 GB of 240 GB)

xc1p login: 

        Welcome to XClarity One Portal 26p.2.0-7909

VM Information:
---------------
-                IPv4: 10.1.1.36
-             Netmask: 255.255.255.0
-             Gateway: 10.1.1.1
-        Internal CNI: 192.168.255.0/25
-                UUID: 89705D12214F40249DB75E00D2D1C522
System Information:
-------------------
-         CPU # Cores: 8
-     CPU Utilization: 18.96 %
-  Memory Utilization: 6.77 % (1083 MB of 15999 MB)
- Storage Utilization: 47.25 % (113.41 GB of 240 GB)

xc1p login: 

It generally ‘refreshes’ or just ‘adds’ new CPU/RAM/… status once in a while. This is how it looks like in the web browser (after accepting self signed certificate warning). As You see it takes a while for it to pick up the DHCP IP address.

 

Seems to work … till next time.

EOF
Top

MMO-2044 V2: Allianz-System – Gemeinsam gegen den Schwarm!

Post by Bernd Dau via Zockertown: Nerten News »

 

🚀 MMO-2044 V2 — Allianz-System ist da! 🚀

Wie wäre es, wenn du nicht allein gegen eine übermächtige Bedrohung kämpfst?

In MMO-2044 V2 schmiedest du jetzt Allianzen mit anderen Spielern, teilst Wissen und koordinierst Angriffe, denn nur gemeinsam können wir den Schwarm besiegen!

🆕 Neues Allianz-System:

  • Gründe deine eigene Allianz mit Name, Beschreibung und Motto
  • Lade Spieler ein oder trete öffentlichen Allianzen bei
  • Verwalte Mitglieder als Leader oder Officer
  • Teile Wissen – Allianz-Mitglieder sehen alle gemeinsamen Forschungen

🎯 In der nächsten Version kommen:

  • 🎯 Koordinierte Flottenangriffe (Synchronisiertes Eintreffen ±2 Minuten)
  • 🔍 Spionage-Sonden für Schwarm-Erkundung
  • 📜 Progressive Enthüllung der Schwarm-Bedrohung
📢 Beta-Test starten! Die erste Beta mit Allianz-System steht kurz vor der Veröffentlichung!
Wann? Nächstes Wochenende
Teste die Allianz-Funktionen und melde Bugs!

Bleibt dran – der Schwarm kommt! 🪐

Top

FreeBSD 14.5-RC1 Available

Post by FreeBSD Newsflash via FreeBSD News Flash »

The first Release Candidate build for the FreeBSD 14.5 release cycle is now available. ISO images for the amd64, i386, armv7, aarch64, powerpc, powerpcspe, powerpc64, powerpc64le, and riscv64 architectures are FreeBSD mirror sites.
Top

FreeBSD backup libraries such as base/FreeBSD-kerberos-lib-backup-libkrb5profile.so

Post by Dan Langille via Dan Langille's Other Diary »

I build my own FreeBSD packages using poudriere. I do this for various reasons, which include:

  • Getting security updates faster because I build nightly
  • Some packages I install use non-default build options

One of the monitoring checks I have in place will identify any installed package which is not in the package repository. That helps me identify any failed package builds or packages I have build once, installed, and did not added to my package building system. You can find that check in my git repo of nagios things.

Case in point:

[12:33 r730-01 dvl ~] % pkg version -vRL= | grep orphaned
FreeBSD-kerberos-lib-backup-libkrb5profile.so.122-20260717191016 ?   orphaned: base/FreeBSD-kerberos-lib-backup-libkrb5profile.so.122
FreeBSD-lldb-backup-libprivatelldb.so.19-20260717191013 ?   orphaned: base/FreeBSD-lldb-backup-libprivatelldb.so.19
FreeBSD-runtime-backup-libpam.so.6-20260717191009 ?   orphaned: base/FreeBSD-runtime-backup-libpam.so.6
FreeBSD-runtime-backup-libprivatezstd.so.5-20260717191009 ?   orphaned: base/FreeBSD-runtime-backup-libprivatezstd.so.5
lmdb-backup-liblmdb.so.0-20260803225943 ?   orphaned: databases/lmdb-backup-liblmdb.so.0
mesa-libs-backup-libgallium-26.1.3.so-20260803225944 ?   orphaned: graphics/mesa-libs-backup-libgallium-26.1.3.so

I don’t build my own FreeBSD-base packages. There is no reason for that. I might, one day. But not now.

Notice how all these orphaned packages contain backup in their name.

I asked on Mastodon some time ago. I got an answer. It pointed to a man page. I forgot. I posted again. I got an answer. Thanks Lěng Shuāng (冷霜).

I was pointed to man pkg.conf which contains:

     BACKUP_LIBRARIES: boolean
		  If set to true and if an upgrade will remove a library  (typi-
		  cally  due  to the library version number having been bumped),
		  then pkg(8) will back up the library to the  path  defined  by
		  BACKUP_LIBRARY_PATH.	 A  package containing the backed up li-
		  brary will be created.  This package is named after the origi-
		  nal  package	containing  the   library,   with   the   suffix
		  `-backup-libraries'  appended.   The	package  version will be
		  bumped whenever an additional library is backed up.	Default:
		  NO.

OK, let’s check those pkg.conf files.

Yes, most of my hosts had that configuration setting. Not all of the hosts had the orphaned packages problem. However, every one which did have orphaned FreeBSD-base packages, also had that setting.

Clean up on aisle 3

Here I go, cleaning up that host:

[12:36 r730-01 dvl ~] % sudo pkg delete FreeBSD-kerberos-lib-backup-libkrb5profile.so.122 FreeBSD-lldb-backup-libprivatelldb.so.19 FreeBSD-runtime-backup-libpam.so.6 FreeBSD-runtime-backup-libprivatezstd.so.5
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 4 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
	FreeBSD-kerberos-lib-backup-libkrb5profile.so.122: 20260717191016
	FreeBSD-lldb-backup-libprivatelldb.so.19: 20260717191013
	FreeBSD-runtime-backup-libpam.so.6: 20260717191009
	FreeBSD-runtime-backup-libprivatezstd.so.5: 20260717191009

Number of packages to be removed: 4

Proceed with deinstalling packages? [y/N]: y
[1/4] Deinstalling FreeBSD-kerberos-lib-backup-libkrb5profile.so.122-20260717191016...
[1/4] Deleting files for FreeBSD-kerberos-lib-backup-libkrb5profile.so.122-2026[1/4] Deleting files for FreeBSD-kerberos-lib-backup-libkrb5profile.so.122-20260717191016:   0%
FreeBSD-kerberos-lib-backup-libkrb5profile.so.122-20260717191016: missing file /root/usr/local/lib/compat/pkg/libkrb5profile.so.122
[1/4] Deleting files for FreeBSD-kerberos-lib-backup-libkrb5profile.so.122-20260717191016: 100%
[2/4] Deinstalling FreeBSD-lldb-backup-libprivatelldb.so.19-20260717191013...
[2/4] Deleting files for FreeBSD-lldb-backup-libprivatelldb.so.19-2026071719101[2/4] Deleting files for FreeBSD-lldb-backup-libprivatelldb.so.19-20260717191013:   0%
FreeBSD-lldb-backup-libprivatelldb.so.19-20260717191013: missing file /root/usr/local/lib/compat/pkg/libprivatelldb.so.19
[2/4] Deleting files for FreeBSD-lldb-backup-libprivatelldb.so.19-20260717191013: 100%
[3/4] Deinstalling FreeBSD-runtime-backup-libpam.so.6-20260717191009...
[3/4] Deleting files for FreeBSD-runtime-backup-libpam.so.6-20260717191009:   0[3/4] Deleting files for FreeBSD-runtime-backup-libpam.so.6-20260717191009:   0[3/4] Deleting files for FreeBSD-runtime-backup-libpam.so.6-20260717191009: 100%
[4/4] Deinstalling FreeBSD-runtime-backup-libprivatezstd.so.5-20260717191009...
[4/4] Deleting files for FreeBSD-runtime-backup-libprivatezstd.so.5-20260717191[4/4] Deleting files for FreeBSD-runtime-backup-libprivatezstd.so.5-20260717191[4/4] Deleting files for FreeBSD-runtime-backup-libprivatezstd.so.5-20260717191009: 100%

These packages are not FreeBSD-base related and are for me to investigate later.

[12:37 r730-01 dvl ~] % pkg version -vRL= | grep orphaned
lmdb-backup-liblmdb.so.0-20260803225943 ?   orphaned: databases/lmdb-backup-liblmdb.so.0
mesa-libs-backup-libgallium-26.1.3.so-20260803225944 ?   orphaned: graphics/mesa-libs-backup-libgallium-26.1.3.so
[12:37 r730-01 dvl ~] % 

I removed the setting

I am sure I added that configuration setting on my own. It was not a recommendation I had seen. I checked my ansible configuration. That setting is not specified there.

I also ran this query on each host (which runs jails):

[12:52 r730-01 dvl ~] % grep BACKUP /jails/*/usr/local/etc/pkg.conf
[12:53 r730-01 dvl ~] % 
Top

Two Alleged ‘TeamPCP’ Hackers Arrested in Australia

Post by Brian Krebs via Krebs on Security »

Authorities in Australia have arrested two men believed to be members of TeamPCP, a prolific cybercrime and data extortion group blamed for perpetrating the longest running spree of software supply chain attacks ever.

In a statement released today, the Australian Federal Police (AFP) said two men from Western Australia, aged 21 and 23, were arrested in connection with a “sophisticated cybercrime syndicate that allegedly created malicious open-source software to rob thousands of global businesses.”

The AFP did not name the defendants, but KrebsOnSecurity learned the 21-year-old suspect’s real identity in June, and has been communicating with him ever since. This story includes interviews with TeamPCP’s self-described spokesperson, and examines clues left behind by the TeamPCP leader that likely led to his undoing.

TeamPCP vaulted onto the cybercrime scene in late 2025, embedding malicious code in hundreds of open source software tools and extorting victims for profit. Members of the group made headlines by compromising corporate cloud environments using a self-propagating worm dubbed Shai-Hulud, which added malicious code to open source programs maintained by developers whose credentials at public code repositories like GitHub or NPM were phished or stolen.

Writing for Wired, journalist Andy Greenberg described TeamPCP’s core tactic as a kind of cyclical exploitation of software developers.

“The hackers gain access to a network where an open source tool commonly used by coders is being developed,” Greenberg wrote in May. “The hackers plant malware in the tool that ends up on other software developers’ machines, including some who are writing other tools intended to be used by coders. The malware allows TeamPCP’s hackers to steal credentials that let them publish malicious versions of those software development tools, too. The cycle repeats, and TeamPCP’s collection of breached networks grows.”

TeamPCP also has practiced something akin to cyclical recruitment. In May, the source code for the third iteration of Shai-Hulud was published online, and TeamPCP soon after launched a contest offering $1,000 in virtual currency to whichever participant could conduct the largest supply chain operation using the worm’s code. According to the contest rules, participants were scored based on the number of weekly and monthly downloads of packages they compromised — directly incentivizing them to target the most popular code libraries.

A screenshot of a message from TeamPCP’s Telegram account, announcing the supply chain hacking contest. Image: dataminr.com.

“TeamPCP has stated the competition is a recruiting opportunity and they intend to purchase all meaningful access harvested from participants’ campaigns,” the security firm Dataminr wrote. “The $1,000 XMR (Monero) prize is a recruitment floor and has been dismissed by the actor as ‘just like participation trophy,’ adding ‘if you find something good you will be paid way more,’ confirming the contest’s true function as talent identification and malicious access acquisition at scale.”

In March, TeamPCP executed a supply chain attack targeting AI infrastructure by compromising the code for LiteLLM, an open source AI gateway that connects users to more than 100 different large language models. A recent analysis by the security firm CloudSEK found TeamPCPs attack on LiteLLM harvested cloud service keys and other secrets from more than 2,500 organizations, including many of the world’s top technology companies.

In May, TeamPCP claimed credit for compromising at least 3,800 code repositories at the Microsoft-owned GitHub, after a GitHub developer installed a code extension that was compromised by TeamPCP’s malware.

MEET THE CYBERCATS

Security experts say TeamPCP is less of a hacker group than an amalgamation of threat actors from multiple cybercriminal gangs who sometimes work together toward similar goals.

“It is not a structured criminal crew with a single operator,” said Austin Larsen, a principal threat analyst with the Google Threat Intelligence Group. “It is a peer community of individually-skilled actors, with one clear center of gravity.”

That center of gravity is George Prepakis, an accomplished security researcher and self-described exploit developer who operates the Twitter/X profile @kernelstub. Earlier this year, @kernelstub tweeted a public invite link to a Matrix chat server he created and dubbed “Cybercats,” and TeamPCP and several other cybercrime entities have been using this server to communicate daily for the past several months.

A screenshot of the Matrix chat server “Cybercats,” whose members used hacker handles associated with multiple distinct cybercrime groups that have occasionally collaborated on a series of supply chain and data ransom attacks over the past nine months.

Kernelstub, like other administrators in the Cybercats chat, has been using his Twitter/X profile name as his handle in these Matrix communications, frequently tweeting references to other members and to conversations taking place in the Cybercats chat. In a number of cases, the corresponding X accounts for members of the Cybercats chat taunted cybercrime victims publicly before the incidents were reported in the news media.

The Cybercats administrator listed at the top of the screenshot above — “Boxturtle” — is a close associate of TeamPCP who has been tweeting about the group’s conquests under the name @xpl0itrsturtle. This handle corresponds to a data breach broker active on Breachforums and Darkforums who has been selling data stolen in a wave of recent breaches at automobile manufacturers, including BMW Group, Audi, Honda, Mercedes-Benz, Volvo and Toyota, as well as data allegedly taken from Snapchat and SportRadar.

The data leak site for the extortion group or handle “xpl0itrs.”

The Cybercats administrator “SeesawSec” in the screenshot above is the alias of whoever is behind the cybercrime group known as Fulcrumsec, which recently claimed credit for data extortion attacks against the pharmaceutical giant Novo Nordisk, the data broker LexisNexis, and Avnet, a Fortune 500 distributor of electronic components.

The data leak site of Fulcrum Security, a.k.a. Fulcrumsec.

The Cybercats administrator “@pcpcasper” also has been using a similar name on X to discuss TeamPCP’s attacks and victims. This person has an extensive message history on Telegram, where their messages and shared videos show @pcpcasper is an active and vocal member of the National Socialist Network, a neo-Nazi political organization based in Australia.

At one point in these chats, @pcpcasper shared videos and images of what they claimed was their cat, and several of those videos place this user in Western Australia. One source close to the investigation told KrebsOnSecurity that @pcpcasper was one of the two arrested, a claim supported by messages that @kernelstub posted online this morning.

The Cybercats member roster pictured above also features an administrator with the username “T,” which is short for the now-banned Twitter/X profile @pcpcats, the account operated by the self-described TeamPCP spokesperson who was arrested today. As we’ll see in a moment, @pcpcats also is from Western Australia.

By the time @kernelstub tweeted a public invite link to the Cybercats Matrix server, T/@pcpcats was posting only infrequently to the group chat, with other members often inquiring as to his whereabouts and well-being. The group’s collective concern related to @pcpcats’s tendency to blame his increasingly extended absences on the use of hallucinogens and other narcotics that kept him awake for days on end, but also caused him to crash in bed for several days after the highs wore off.

WHO IS THE TEAMPCP LEADER?

The Cybercats member @pcpcats has used multiple nicknames on the cybercrime forums, including EllisD25/LSD on Darkforums, BulkDMT on Breachstars, and Express on Breachforums. These accounts are linked because they all advertised the same Tox ID and/or Session ID as instant message contact handles in their cybercrime forum posts. BulkDMT was also known on the forums as DMT Host, which was a virtual private server (VPS) hosting service that was peddled on Darkforums and Breachstars.

DMT Host/EllisD25, posting on the English-language cybercrime community DarkForums in September 2025. Image: ke-la.com.

According to the cyber intelligence firm Intel 471, Express registered on Breachforums using the email address shitstickpp@gmail.com. Intel 471 finds Express posted on Breachforums across a two-month period in 2025 using four different Internet addresses located in South Africa. On July 30, 2025, Express announced on Breachforums they were selling access to 14 gigabytes of data stolen from South Africa’s State Information Technology Agency.

The threat intelligence platform Flashpoint recorded more than a year’s worth of messages from the TeamPCP leader’s alter ego on Telegram — Persy_PCP —  who claimed they split their life living between two countries [full disclosure: Flashpoint is an advertiser on this blog]. “I have these [files] as well, problem is these are in another country,” Persy_PCP explained to another user inquiring about a stolen data set in November 2025.

Later that month, Persy_PCP complained, “My whole country is racist and they want people like me dead.” Flashpoint records show BulkDMT shared in September 2025 that “this country is going to fucking starve when they take the farmers land,” a likely reference to white landowners in South Africa who claim to be targeted by an ongoing genocide campaign.

This tracks with public reporting on TeamPCP. Cyberscoop reported in June that Google had traced TeamPCP’s residential and mobile Internet address connections to South Africa, “indicating the primary operator was located there during at least some of its attacks.”

BulkDMT also shared on the group chat at Breachforums that they were recovering from an addiction to methamphetamine. “My life is kinda fucked rn [right now], but that’s fine and there isn’t really a point in pouring so much emotional energy into that fact, my parents had money but I unfortunately got really addicted to some things so I don’t get to benefit from that. As long as I continue to survive, stay sober, and move closer towards my goals that’s enough drive and meaning.”

The identity threat protection company SpyCloud finds shitstickpp@gmail.com shows up in the registration of an account called ChristmasSnow on the cybercrime community Raidforums in 2022. Nearly all of the Internet addresses used to access that account came from ISPs in Perth, Australia, SpyCloud found.

KrebsOnSecurity looked up all of those Perth IP addresses in passive DNS records maintained by DomainTools.com, and found one of them — 211.27.196.111 — for several years was used as a private file server by a family in Perth with the last name of Thomson. Those records show at least three hosts — ithomson.direct.quickconnect.to (a remote Synology server), kthomson0061.direct.quickconnect.to, and joshuawthomson39.myqnapcloud.com (a QNAP network storage device) — persisted at that address between 2022 and 2025.

Searching on “joshuathomson39” in the breach tracking service Constella Intelligence reveals an account at the freight forwarding company kwe.com created in the name of Joshua Thomson from Perth, Australia. The open source intelligence platform Epieos finds the phone number attached to that kwe.com account was used to register a Facebook profile for Josh Thomson, which says his family includes a brother named Ruben, his father Ian, and his mom Cindy.

That Facebook profile also says Josh and his family are originally from Pietermaritzburg, in KwaZulu-Natal, South Africa, but currently living in Cottesloe, a beach-side suburb of Perth. A search in DomainTools for Ian Thomson and Australia unearthed five domains by the same registrant, including securecomputing.au, thomson.org.au, and thomsonfamily.net.au. Ian Thomson is a dentist in Cottesloe, and a biography says he graduated from The University of the Witwatersrand in Johannesburg, South Africa.

Constella finds a joshua@thomson.org.au registered a number of accounts online, but Josh doesn’t seem to have much of a connection to dodgy cybercrime forums. His brother Ruben, on the other hand, has quite the presence on these communities, dating back to at least 2018. Constella reports ruben@thomson.org.au frequently reused the password “joshuathomson1,” and Constella further finds that password was used by just a handful of accounts, including yolosolo17@gmail.com and surfinup8@gmail.com.

According to Intel 471, surfinup8@gmail.com was used to register the user Yolosolo17 on the crime forum Altenen in 2018, and that user account was registered from the Perth address 110.141.230.15. On Altenen, Yolosolo17 advertised free web proxies, as well as the domain rubenthomson.com, which was at one point used to sell steeply discounted iPhones. DomainTools says rubenthomson.com was hosted at 110.141.230.15 and registered to surfinup8@gmail.com.

A cached copy of the domain rubenthomson.com from 2017 shows a login page underneath a banded stack of money. Image: archive.org.

SpyCloud reports 10.141.230.15 was used by the email address sheepstealing@gmail.com on Raidforums and surfinup8@gmail.com on Nulled, and that the same IP was used by the email addresses ian@thomsonfamily.net.au, jasper@yakuza.cc, and rubenthomson1@gmail.com. SpyCloud also shows that sheepstealing Gmail address is tied to the accounts Sheep420, YoloSolo117 and Yakuza.cc on Raidforums, and to the account “Sheep Stealing” on Hackforums. Intel 471 says sheepstealing@gmail.com was used to register the account DingoFlour on Breachforums in October 2023, as well Sheepx on Altenen.

Epieos reports that ruben@securecomputing.au is tied to an Airbnb account for Ruben, who described himself as a Web developer who went to school at the University of Western Australia and was living outside the country. “Hey, I’m Ruben, my friends call me Ellis. I’m a Perth creative who occasionally books rooms when visiting family and for photography.”

Epieos also finds sheepstealing@gmail.com registered an upwork.com profile under the name Ruben, who said his main skills are setting up secure server hosting solutions and PHP full-stack Web development.

“I’m familiar with Linux, working with relational databases (SQL),” the Upwork profile reads. “I also script in Python mainly for writing social media bots.”

The Upwork profile for Ruben Thomson in Cottesloe, Australia.

Epieos further discovered sheepstealing@gmail.com is connected to a Microsoft account for Ruben Thomson, and to a now-defunct GitHub account called XmasSnow/XmasSnowisBack that scammed people on the forums in 2022 by claiming to sell exclusive exploits for recently-released software patches (recall that shitstickpp@gmail.com was used to register a forum account named ChristmasSnow).

This same sheepstealing email address registered a Twitter/X account in 2026 called “Gone Fishing” that lists its location as South Africa. That Gmail account also left several reviews for businesses listed on Google Maps over the past seven years, but all of those establishments are located on the west coast of Australia.

Business reviews in Western Australia left by the Google account sheepstealing at gmail.com.

The people search service Pipl finds a 21-year-old Ruben Thomson in Western Australia who has a phone number ending in 979. A lookup on that number at Epieos reveals it is connected to a TikTok account under the name Ellis, and to a PayPal account in the name of Ruben Thomson.

Finally, a search on the name Ruben Thomson from Cottesloe at the Australian government’s record of registered businesses finds he has incorporated or served as an official in multiple companies created since 2024, including Secure Computing Solutions, Tensor Industries, and another entity ironically named OPSEC Express. Recall that Express was BulkDMT’s nickname on Breachforums.

Australian companies connected to Ruben Thomson. Image: abr.business.gov.au.

It’s ironic because OPSEC is short for the term “operational security,” which refers to techniques and behaviors used to obfuscate and compartmentalize one’s real-life identity online, and using your cybercrime handle as part of your own company name is very much the antithesis of that practice.

There is at least one other major opsec failure by Ruben that exposed a link to TeamPCP. In June 2025, someone using the name Ruben Thomson registered on HackerOne, a popular “bug bounty” program that seeks to reward and recognize researchers who agree to work with affected software vendors to help fix the flaws before publishing about their findings. What was Ruben Thomson’s chosen HackerOne username? Deadcatx3, a nickname that has been flagged by multiple security firms as an alias used by TeamPCP.

The HackerOne profile for “Ruben Thomson” uses the nickname Deadcatx3, which multiple security firms have concluded is an alias used by TeamPCP. Image credit: flare.io.

INTERVIEW WITH ELLIS

In early July 2026, not long after having discovered clues about Ellis’s real life identity, KrebsOnSecurity interviewed the TeamPCP leader via Signal, where he was remarkably open about his activities and personal struggles [for the sake of simplicity, the TeamPCP spokesperson will be referred to from here on as Ellis].

Ellis claims he stopped doing cybercrime for TeamPCP in March 2026 — just before the attacks that compromised LiteLLM — and that at least one other individual has taken over the group’s leadership since then. Ellis shared that a year earlier he had just completed the latest in a series of detox and sobriety programs, and was two months sober when he reconnected with some old friends from the malware development scene.

“One year ago I needed help monetizing some [GitHub credentials], I was two months sober and needed a distraction and something to keep busy as well as people to speak to,” Ellis said. “I had largely disconnected from my old circle, they had become very toxic and I needed to get away from the substances. Previously I had done some mass exploitation campaigns and grew up doing [malware development] and [capture the flag] contests. There were some friends who were also vending but had stopped a while, and one of them introduced me to some chats where I posted access for sale.”

Prior to that, Ellis said, he was homeless and hopping between “some very unstable places.”

“Blackhatting is fun,” he said. “There are actual rewards and incentives to learn and you grow with your team. Without qualifications, no employer will even take the time to hear you out.”

Ellis claims he’s earned a grand total of about $20,000 for his activities with TeamPCP, and that it was never about the money or fame for him. Asked whether his experiences with TeamPCP might prepare him for gainful employment in a legitimate IT job, Ellis said he doubted it.

“I am nowhere close to a skill level where I am comfortable, and this would take maybe half a decade of further experience,” he said. “I no longer have to choose between rent and food for that I’m grateful and so are the team members.”

Ellis expressed no remorse over his cybercrime activities, and said he was grateful for the friendships and relationships built throughout his engagement with TeamPCP. The young hacker also seemed resigned to his fate, and told KrebsOnSecurity that he’ll accept the consequences if he’s ever arrested.

“If I’ve already been found out then its out of my control, I’ll make peace with that,” he said. “Honestly, I think someone like me needs a lot of help that prison just can’t provide. If I had the funds to study different parts of the field and closer guidance, this would have turned out differently. But that’s a pipe dream and we both know this.”

It is clear from reading Ellis’s posts to the group’s Matrix server chats that his struggles with sobriety are ongoing. On Thursday, June 25, Ellis told @kernelstub he was about to “trip” with his “homie.”

“What kind,” @kernelstub inquired.

“Ketty and some DMT,” Ellis replied, referring to the dissociative anesthetic ketamine and dimethyltryptamine (DMT), a powerful psychedelic compound that is found naturally in some plants but is also synthetically produced in underground lab environments. “There’s a little 2cb so we might throw that in the mix,” he continued, referring to another psychedelic compound by its chemical shorthand.

Roughly two weeks before his arrest, Ellis told KrebsOnSecurity he was ready to leave his life of crime behind and was prepared to turn himself in, but that in the meantime he was making plans to tie up loose ends.

Less than 24 hours later, the TeamPCP leader posted an image on Telegram showing a yellowish powdered substance in a baggie and on a scale, possibly synthetic DMT. The image shows the powder being weighed next to a series of small vape cartridges, two of which are open on the table in front of the photographer.

An image posted by the TeamPCP leader to Telegram, advertising his acquisition of some type of psychoactive substance, most likely a synthetic version of the powerful hallucinogen known as DMT.

The two defendants were arrested Wednesday morning. The AFP said the men face a combined 14 cybercrime offenses and are scheduled to appear in Perth Magistrates Court today.

Charlie Eriksen is a security researcher at Aikido Security who has closely followed TeamPCP’s cybercrime campaigns. Eriksen said TeamPCP are a good example of a new kind of threat actor that does not fit neatly into the usual categories.

“They are not a state actor, not quite organized cybercrime, and not purely ideological,” he said. “Their motivations seem to mix money, disruption, attention, and ideology.”

Eriksen said that historically there has always been a meaningful gap between reading about an attack technique and being able to reliably turn it into an operational campaign, but that large language models (LLMs) and artificial intelligence increasingly are helping threat actors to bypass that knowledge gap.

“You had to understand the research, adapt the code, troubleshoot it, build infrastructure around it, and then repeat that process across different targets,” he said. “LLMs have compressed that gap significantly.”

According to Eriksen, this creates an environment where threat actors suddenly have the ability to operate at significant scale without having developed the operational discipline that traditionally accompanies that level of capability. Put another way, it sets the stage for cybercriminals who are capable enough to cause significant damage, but not necessarily careful enough to understand or care about the consequences.

“They can be noisy, they can make mistakes,” he said. “They can leave evidence everywhere. They can take risks that a professional criminal group or intelligence service would consider completely unacceptable. But that does not necessarily make them less dangerous. In some ways, it can make them more dangerous.”

In a recent blog post, Eriksen called TeamPCP’s Shai-Hulud worm the “best thing to happen to supply chain security,” because it forced GitHub and other public coding platforms to erect new security safeguards.

In direct response to TeamPCP’s broad success at pushing poisoned versions of popular software packages, GitHub in late July introduced a three-day “cooldown” mechanism for Dependabot, the platform’s tool for auto-fetching newly shipped updates for any package dependencies. Cooldown periods are designed to help buy time for security tools and package maintainers to identify and remove any compromised versions. Other coding ecosystems like Python and various JavaScript platforms also added support for cooldown periods this year amid growing calls from security experts about the need for more widespread adoption of the safety feature.

Eriksen said TeamPCP’s legacy is that they achieved in the span of a few months what the supply chain security community has been unable to do for years.

“They managed to wake up Microsoft to the fact that they had become negligent in terms of security,” Eriksen said. “By compromising GitHub and stealing their source code, they humiliated Microsoft into action, making them finally act on what we had been asking them to do and take seriously for a while now.”

Update, 10:08 a.m. ET: A story this morning from ABC News in Australia confirms Ruben Ian Thomson of Cottesloe was one of the two arrested. The 23-year-old suspect thought to be @pcpcasper, Michael Gaebler, also was arrested in Perth. ABC News reports that Thomson was denied bail (Mr. Gaebler’s attorney reportedly did not request bail for his client), and that both men will be held in custody until their next court appearance on September 18.

Top

Launching Route 53 Files

Post by Colin Percival via Daemonic Dispatches »

I'm excited to announce Route 53 Files, a new file system that seamlessly connects any AWS compute resource with Amazon's highest-availability database.

Top

Strom für ein elektrisches Deutschland

Post by Kristian Köhntopp via Die wunderbare Welt von Isotopp »

Deutschland verbraucht heute sehr viel Energie, aber nur ein kleiner Teil davon ist Strom. Das ist kein Argument gegen Elektrifizierung, sondern ihr größter Vorteil.

Ein Liter Diesel enthält ungefähr 10 kWh Energie. Ein Dieselauto mit 6 l/100 km verbrennt also 60 kWh/100 km. Am Rad kommen grob 20 kWh/100 km an; der Rest wird Wärme. Ein Elektroauto braucht für die gleiche Strecke meist weniger als diese 20 kWh aus der Batterie.

Das Prinzip gilt nicht nur für Autos. Fossile Energie wird meist verbrannt, um Wärme oder Bewegung zu erzeugen. Elektrische Motoren, Wärmepumpen und elektrische Prozesse umgehen einen großen Teil dieser Verluste.

Ich habe deshalb eine grobe, aber konkrete Rechnung gebaut: historische deutsche Viertelstundenwerte aus 2024, auf ein elektrifiziertes Deutschland hochskaliert, mit Wind, Solar, Vier-Stunden-Batterien und Gaskraftwerken als letzter Reserve. Der Quellcode liegt auf GitHub: isotopp/strommodell .

Die Zielgröße: rund 1.100 TWh Strom

Die AG Energiebilanzen hat vollständige Anwendungsbilanzen derzeit bis 2024. Das detaillierte Energieflussbild 2024 weist aus:

  • 10.542 PJ (2.928 TWh) Primärenergieverbrauch;
  • 8.095 PJ (2.249 TWh) Endenergieverbrauch;
  • 1.664 PJ (462 TWh) davon Strom;
  • 6.431 PJ (1.786 TWh) übrige Endenergie.

Für die Frage nach einem elektrischen Deutschland ist der Endenergieverbrauch die sinnvolle Basis. Der Primärenergieverbrauch enthält die Verluste heutiger Kohle- und Gaskraftwerke bereits. Wer ihn nimmt und dann fossile Energie noch einmal pauschal durch drei teilt, rechnet einen Teil der Verbesserung doppelt.

Die absichtlich grobe Rechnung lautet:

$$ E_\text{elektrisch} = E_\text{Strom} + \frac{E_\text{übrige Endenergie}}{3} $$

also:

$$ 1.664\ \text{PJ} + \frac{6.431\ \text{PJ}}{3} = 3.807\ \text{PJ}. $$

Das sind 1.058 TWh im Jahr. Mit Netz- und Speicherverlusten und der unvermeidlichen Ungenauigkeit einer solchen Faustformel runde ich auf 1.100 TWh/a.

Zum Vergleich: Der heutige Stromverbrauch einschließlich Netzverlusten betrug 2024 nach SMARD-Daten der Bundesnetzagentur 465,5 TWh. Die Zielgröße ist damit das 2,36fache der heutigen Stromarbeit.

Reale Viertelstunden statt Jahresmittel

1.100 TWh im Jahr entsprechen einer mittleren Leistung von 126 GW:

$$ \frac{1.100 TWh}{8.760 h} = 126 GW. $$

Ein Stromsystem muß aber in jeder Viertelstunde funktionieren. Deshalb verwende ich die öffentliche deutsche 2024er Zeitreihe von Fraunhofer Energy-Charts : Last, Solar, Wind an Land und Wind auf See, jeweils in 15-Minuten-Schritten.

Die reale Lastreihe hat 465,503 TWh. Sie wird proportional auf 1.100 TWh skaliert. Ihre Form bleibt dabei unverändert. Das ergibt eine Spitzenlast im konkreten 2024er Profil von 179,0 GW.

Für jede Viertelstunde werden PV, Wind an Land und Wind auf See getrennt skaliert:

$$ P_\text{Szenario}(t) = P_\text{beobachtet}(t) \cdot \frac{K_\text{Szenario}}{K_\text{Referenz}}. $$

Die Referenzleistung ist für 2024 der Mittelwert aus dem Anlagenbestand Ende 2023 und Ende 2024. Das ist bei starkem PV-Zubau besser als blind mit dem Jahresendwert zu rechnen.

Dann bleibt die Residuallast:

$$ R(t) = D(t) - S(t) - W_\text{an Land}(t) - W_\text{auf See}(t). $$

Bei Überschuß lädt die Batterie, danach wird abgeregelt. Bei Defizit entlädt sie, danach liefert Gas. Es gibt im Modell keine Importe und keine ungedeckte Last.

Batterie für Stunden, Gas für Flauten

Die Batterie hat in den Szenarien vier Stunden Energieinhalt: 100 GW Batterie-Leistung bedeuten 400 GWh Energie. Sie lädt und entlädt jeweils mit 90 % Wirkungsgrad.

Das verschiebt Solarstrom vom Mittag in den Abend und glättet kurze Windschwankungen. Es ist aber kein saisonaler Speicher. Wenn bei hoher Last Wind und Sonne über viele Stunden praktisch ausfallen, ist eine Vier-Stunden-Batterie leer.

Gaskraftwerke decken ausschließlich den Rest:

$$ G(t) = \max(0, R(t) - B_\text{entladen}(t)). $$

Die entscheidenden Ausgaben sind daher getrennt:

  • Gasarbeit: Wie viele TWh müssen im Jahr aus Gas kommen?
  • Gasleistung: Wie viele GW müssen im schlimmsten Viertelstundenschritt bereitstehen?

Die zweite Zahl bestimmt die Größe der Reserveflotte, nicht die erste.

Vier Szenarien

Szenario 0 benutzt den Bestand Ende 2024: 99,3 GW PV, 63,53 GW Wind an Land, 9,215 GW Wind auf See und 12,67 GW / 18,65 GWh Batteriespeicher. Die Batterie hat damit heute nur etwa 1,5 Stunden Dauer.

Szenario PV Wind an Land Wind auf See Batterie
0: Iststand 2024 99,3 GW 63,53 GW 9,215 GW 12,67 GW / 18,65 GWh
A: knapp 300 GW 250 GW 70 GW 50 GW / 200 GWh
B: Referenz 400 GW 300 GW 80 GW 100 GW / 400 GWh
C: viel Überschuß 500 GW 350 GW 100 GW 150 GW / 600 GWh

Szenario 0 ist ausdrücklich nicht die heutige deutsche Strombilanz. Es setzt den heutigen Wind-, PV- und Batteriepark auf die Last eines elektrifizierten Deutschlands und fragt: Was bliebe dann für Gas übrig?

Ergebnis: Gasarbeit fällt, Gasleistung fast nicht

Der Modelllauf für 2024 ergibt:

Szenario Gasleistung Gasarbeit Stunden mit Gas Abregelung
0: Iststand 2024 163,3 GW 896,0 TWh 8.784 h 0,0 TWh
A: knapp 156,7 GW 319,4 TWh 5.548 h 56,9 TWh
B: Referenz 156,6 GW 214,2 TWh 3.545 h 127,5 TWh
C: viel Überschuß 156,5 GW 133,4 TWh 2.086 h 253,3 TWh

Das Resultat ist klar.

Von Szenario 0 zu C sinkt die Gasarbeit von 896 auf 133 TWh, um 85 Prozent. Die Zahl der Viertelstunden mit Gaseinsatz sinkt von praktisch dem ganzen Jahr auf 2.086 Stunden, also um 76 Prozent. Das sind weiterhin nicht „wenige Tage“: Selbst im großen Szenario C läuft Gas noch in rund einem Viertel des Jahres, wenn auch oft nur mit kleiner Leistung.

Die Gasleistung sinkt dagegen kaum: von 163,3 auf 156,5 GW. Am 6. November 2024 um 16:30 UTC liegt die hochskalierte Last bei 157,2 GW. Wind und Solar liefern im Szenario C zusammen nur 0,66 GW. Die Batterie ist zu diesem Zeitpunkt leer. Genau für diese Lage muß die Gasflotte da sein.

Mehr Wind, Solar und Batterie machen Gas deshalb von der dominanten Energiequelle zur Rest- und Dunkelflautenenergie. Sie machen die Gaskraftwerke aber nicht überflüssig.

Das wahrscheinliche Ergebnis ist eine große Flotte schneller Gaskraftwerke als Peaker auf Abruf. Sie verkauft wenig Energie, muß aber im kritischen Moment vollständig verfügbar sein. Das bezahlt man nicht sinnvoll allein über verkaufte MWh, sondern über eine Vergütung für vorgehaltene gesicherte Leistung.

Die Abregelung in B und C ist kein Fehler. Sie ist der Preis dafür, daß Wind und Solar auch in schlechten Stunden noch ausreichend oft viel Energie liefern. Zusätzliche Speicher oder flexible Verbraucher können einen Teil dieser Überschüsse nutzen; sie ändern aber nicht die einfache Tatsache, daß eine lange, dunkle und windarme Winterphase gesicherte Leistung braucht.

Der vollständige Rechenweg ist reproduzierbar:

uv run strommodell run scenarios/2024.yaml --output results/2024
uv run strommodell report results/2024

Grenzen des Modells

Das ist eine Daumenschätzung mit einer realen Jahreszeitreihe, keine Ausbauplanung.

  • Es wird absichtlich nur 2024 gerechnet. Für die Größenordnung reicht das; für eine verbindliche Reserveplanung müßte man viele Wetterjahre und besonders schlechte Dunkelflauten untersuchen.
  • Die Lastform von 2024 wird nur proportional hochskaliert. Wärmepumpen, Elektroautos, Industrie und Elektrolyse bekommen noch keine eigenen, steuerbaren Profile.
  • Die Skalierung verwendet beobachtete Einspeisung. Darin stecken heutige Abregelungen und Netzrestriktionen; ein künftiger, viel größerer Anlagenpark hätte nicht exakt dasselbe Profil pro installiertem GW.
  • Der Anlagenbestand wird nur über den Mittelwert aus Jahresende 2023 und 2024 angenähert. Eine zeitgenaue Zubaukurve wäre besser.
  • Wasserkraft, Biomasse, Fernwärme, Pumpspeicher, europäischer Stromhandel, Netze und Lastmanagement fehlen. Im Modell ist die Welt absichtlich härter: Wind, Sonne, Batterie und danach Gas.
  • Der Batteriespeicher startet halb voll und darf mit einem anderen Ladezustand enden. Das ist bei den Jahreswerten klein, aber für einen vollständigen Systemoptimierer müßte der Jahresübergang zyklisch behandelt werden.
  • Wasserstoff wird nicht modelliert. Ob man für selten laufende Peaker Wasserstoff wirtschaftlich erzeugen und speichern kann, ist eine eigene Frage. Elektrolyseure skalieren ökonomisch bei sehr geringer Auslastung sehr schlecht; das ist kein Problem, das diese einfache Rechnung lösen kann.

Quellen

Top

FreeBSD Foundation Intern Sourojeet Adhikari on Bringing ROCm to FreeBSD

Post by FreeBSD Foundation via FreeBSD Foundation »

For University of Waterloo student Sourojeet Adhikari, an early interest in understanding how computers work eventually grew into a summer spent helping bring AMD’s ROCm GPU computing platform to FreeBSD.

Sourojeet is studying Mathematical Physics and entering the third year of his degree. This summer, he joined the FreeBSD Foundation as an intern, working on a project that combines several of his interests: systems programming, GPU computing, and open source.

We spoke with Sourojeet about his path into open source, the challenges of bringing ROCm to FreeBSD, what he learned from debugging difficult problems, and why students shouldn’t be intimidated by contributing to a large open source project.

An Early Introduction to Open Source

Sourojeet’s interest in open source began when he built his first computer. Without a Windows installation disc or drive available, he turned to what he could find: an Ubuntu 12.04 installation CD sitting on a shelf in his basement.

“I installed Ubuntu and spent days figuring out how to use it,” he said. “From then on, I more or less ran Linux on almost every computer or server I’ve ever owned.”

FreeBSD was also part of his early exposure to open source. One of his parents ran a FreeBSD firewall and another FreeBSD server for a time. The firewall is still running today.

What kept Sourojeet interested was the freedom to explore.

“Open source software generally let me play around with and look deep into the internals of software, modify it, and try to break it,” he said. “That’s why I loved it so much.”

His interest in systems programming came from another question: How can I make my programs faster?

Understanding performance meant understanding what a system was doing under the hood. That curiosity led him deeper into systems programming and, eventually, GPU programming.

Bringing ROCm to FreeBSD

Sourojeet found the FreeBSD Foundation internship through WaterlooWorks, the University of Waterloo’s co-op job board.

His internship project focused on bringing AMD’s ROCm platform to FreeBSD.

Modern computers rely on different components designed for different kinds of work. CPUs are general-purpose processors built to handle a broad range of tasks, while GPUs are highly effective at performing certain kinds of mathematical operations in parallel.

That makes GPUs useful for much more than graphics. Workloads including machine learning, fluid simulations, and data processing can benefit significantly from GPU acceleration.

Platforms such as NVIDIA’s CUDA and AMD’s ROCm give developers the tools needed to take advantage of that computing power. However, these ecosystems have primarily focused on Windows and Linux, with limited native support on FreeBSD.

Sourojeet’s goal was to help change that.

His work involved patching AMD’s LLVM fork, making changes to ROCm’s GPU runtimes, and working to integrate the driver into drm-kmod. Some of the LLVM changes have already been upstreamed, while other pieces of the work are still being merged and developed.

“Slowly but surely, we’ll soon be able to natively run ROCm code on FreeBSD,” he said.

Finding the Bugs That Don’t Want to Be Found

For Sourojeet, one of the most rewarding parts of the internship was also one of the most difficult: debugging.

One issue took several hours to track down and came from a subtle difference between mutable and constant data.

The problem involved LinuxKPI, a compatibility layer in the FreeBSD kernel that helps translate or provide Linux kernel interfaces needed by certain drivers. A Linux function called class_register had changed in newer Linux versions to accept a const structure. The AMD kernel code Sourojeet was porting expected that newer behavior, while the corresponding FreeBSD LinuxKPI implementation still expected a mutable structure.

The mismatch caused a kernel panic.

“It took me maybe three or four hours to figure that one out,” Sourojeet said.

Rather than being discouraged by those problems, he found them to be some of the most enjoyable parts of the work.

“The most fun part was generally debugging the hard-to-find bugs and issues in the code.”

Working Through the Tedious Parts

Not every challenge involved a single difficult bug. Much of the porting work required dealing with Linux-specific macros and functions that did not yet exist on FreeBSD.

Sourojeet first had to determine whether a missing function or code path was actually necessary. Some functionality, such as code related to suspend or sleep behavior, was not required for the initial work and could be temporarily disabled. In other cases, a missing function was too important to remove and needed a temporary stub so development could continue.

The individual changes were not always technically complex. The challenge was often the amount of careful, repetitive work required to move the project forward.

“The actual changes you needed to make to get the driver running weren’t hard or insane,” he said. “Rather, they were just mentally grueling and very tedious.”

That experience also reinforced something Sourojeet wants other potential contributors to understand: meaningful open source work does not always require being an expert.

“If you’re reading this and have some ability to read and write C code, you could probably help out with almost everything.”

Connecting With the Community at BSDCan

During the summer, Sourojeet also attended BSDCan, giving him an opportunity to connect with members of the BSD community in person.

One talk that stood out was Minsoo Choo’s presentation on heterogeneous scheduling on FreeBSD. Sourojeet was particularly interested in the discussion around scheduling costs and performance across different CPU cores.

But some of his favorite parts of BSDCan happened outside the formal sessions.

“The hallway track was a lot more interesting from what I remember,” he said.

Those conversations covered topics ranging from software testing and GPU initialization to heterogeneous memory management on FreeBSD. The latter is especially relevant to where Sourojeet’s own work may go next.

Open Source Is More Approachable Than It Looks

After spending the summer working directly within the FreeBSD ecosystem, Sourojeet came away with an even stronger belief that contributing to open source is more accessible than many new developers assume.

“This internship reinforced my belief that open source is not particularly scary or hard to contribute to,” he said. “It just needs some time and energy.”

His advice to students and first-time contributors is simple: don’t wait until you think you know everything.

“Don’t wait until you think you’re perfect, or the best at coding,” he said. “A lot of the work is tedious debugging, writing docs, or even implementing basic functions.”

Large codebases can look intimidating from the outside, but Sourojeet encourages new contributors to focus on the problem in front of them rather than the size of the entire project.

“It’s just code—maybe a lot of code—but I have faith that anyone who puts in some time and energy can come out with some meaningful changes.”

What’s Next?

Sourojeet expects his work with ROCm and FreeBSD to continue beyond the internship.

The project is already approaching an important milestone: running a simple vector addition workload. The driver can link, load, and run, although there are still issues to resolve in userspace.

From there, Sourojeet expects to spend more time exploring FreeBSD’s memory management systems, particularly the work required to support Heterogeneous Memory Management (HMM).

As for his longer-term career plans, he is keeping his options open.

His ideal path may involve computational fluid dynamics—or, as he jokes, making enough money to eventually retire and hire interns to tackle difficult problems like HMM on FreeBSD. But his experience this summer has also opened another possibility: working on GPU toolchains.

Whatever direction he takes, the internship has given him practical experience solving problems deep within a complex open source system, and a reason to keep contributing.

Sourojeet also credits the people who supported him throughout the project, including Ed Maste, Olivier Certner, Mark Johnson, Jean-Sébastien Pédron, Bjoern Zeeb, Adrian Chadd, Minsoo Choo, and Devin Teske.

His summer is also a reminder for students considering their first open source contribution: you don’t need to understand an entire operating system before you can make an impact. Start with a problem, spend the time to understand it, and contribute what you can.

The FreeBSD Foundation would also like to thank Sourojeet for his contributions throughout the semester. We appreciate the curiosity, persistence, and technical effort he brought to the internship, as well as his willingness to tackle challenging problems and continue pushing ROCm support on FreeBSD forward. 

The post FreeBSD Foundation Intern Sourojeet Adhikari on Bringing ROCm to FreeBSD first appeared on FreeBSD Foundation.

Top

Valuable News – 2026/08/24

Post by Vermaden via 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗 »

The Valuable News weekly series is dedicated to provide summary about news, articles and other interesting stuff mostly but not always related to the UNIX/BSD/Linux systems. Whenever I stumble upon something worth mentioning on the Internet I just put it here.

Today the amount information that we get using various information streams is at massive overload. Thus one needs to focus only on what is important without the need to grep(1) the Internet everyday. Hence the idea of providing such information ‘bulk’ as I already do that grep(1).

The Usual Suspects section at the end is permanent and have links to other sites with interesting UNIX/BSD/Linux news.

Past releases are available at the dedicated NEWS page.

UNIX

FreeBSD 14.5-BETA3 Now Available.
https://lists.freebsd.org/archives/freebsd-stable/2026-August/004283.html

FreeBSD Git Weekly: 2026-08-10 to 2026-08-16.
https://freebsd-git-weekly.tarsnap.net/2026-08-10.html

FreeBSD Git Weekly: 2026-08-17 to 2026-08-23.
https://freebsd-git-weekly.tarsnap.net/2026-08-17.html

In Praise of BSD License.
https://reddit.com/r/freebsd/comments/1vqsb7b/praise_bsd_license/

Migrating from Codeberg Pages to OpenBSD VPS.
https://nemin.hu/vps/

FreeBSD 15 on IBM PowerVM LPAR with Matching pkg(8) Repo for ppc64le Arch.
https://librepower.org/platforms/freebsd/

BSDun Allows Running FreeBSD ELF Executables on Linux.
https://gitlab.com/megastallman/bsdun

NetBSD 11 Lands with RISC-V Support and Lightning Fast VM Boots.
https://theregister.com/os-platforms/2026/08/20/netbsd-11-risc-v/5289713

Say Hello to FreeBSD on PowerVM.
https://librepower.substack.com/p/say-hello-to-freebsd-on-powervm

Specially Crafted NTFS Filesystem Image Allows Root Access on Linux.
https://phoronix.com/news/NTFS3-Vulnerability-For-Root

FreeBSD Foundation Intern Jim Huang Chen on Raspberry Pi Support and Open Source.
https://freebsdfoundation.org/blog/freebsd-foundation-intern-jim-huang-chen-on-raspberry-pi-support-and-open-source/

BSD Weekly – Issue 292.
https://bsdweekly.com/issues/292

NAS Upgrade – Initial Planning.
https://vulcanridr.mataroa.blog/blog/nas-upgrade-initial-planning/

Setup Your Own IPFS Private Network.
https://dataswamp.org/~solene/2026-08-21-your-own-ipfs-network.html

Why Some Satellites Use NetBSD?
https://machaddr.substack.com/p/why-some-satellites-use-netbsd

How to Test MediaTek MT7921 on FreeBSD.
https://lists.freebsd.org/archives/freebsd-wireless/2026-July/004372.html

Analyze FreeBSD Build Process with srcpv(8) Tool.
https://linkedin.com/posts/dteske_freebsd-ugcPost-7494829603732193280-s2fD/

Experimental Roblox Compatibility Runtime for Linux and FreeBSD.
https://github.com/komaruworld/mocktail

UNIX/Audio/Video

Running Large Language Model with Ollama on FreeBSD.
https://youtube.com/watch?v=6MRvKcWse7c

Responsible Replication with Zelta on ZFS.
https://youtube.com/watch?v=G3weooQqcXw

BSD Now 677: Butler at Your Service.
https://www.bsdnow.tv/677

Hardware

AMD Chipset Cards Adding PCIe/SATA Lanes Emerge in China.
https://hwcooling.net/en/amd-chipset-cards-adding-pcie-sata-lanes-emerge-in-china/

This is Not Computer for You: Appreciation of Struggle.
https://stevengharms.com/posts/2026-08-21-this-is-not-the-computer-for-you-an-appreciation-of-struggle/

Life

Need for Speed.
https://filfre.net/2026/08/a-need-for-speed/

IP Problem Hiding in AI Generated Code.
https://medium.com/@markus_brinsa/the-ip-problem-hiding-in-ai-generated-code-88b30071e0a2

Other

Nintendo Wipes Out 400+ Switch Emulator Repos in Single Day GitHub Sweep.
https://torrentfreak.com/nintendo-wipes-out-400-switch-emulator-repos-in-single-day-github-sweep/

Usual Suspects

BSD Weekly.
https://bsdweekly.com/

DiscoverBSD.
https://discoverbsd.com/

BSDSec.
https://bsdsec.net/

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

BSDTV.
https://bsky.app/profile/bsdtv.bsky.social

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

BSDJedi.
https://youtube.com/@BSDJedi/videos

RoboNuggie.
https://youtube.com/@RoboNuggie/videos

GaryHTech.
https://youtube.com/@GaryHTech/videos

Sheridan Computers.
https://youtube.com/@sheridans/videos

82MHz.
https://82mhz.net/

EOF
Top

Building server-key-injection by specialization

Post by Kristian Köhntopp via Die wunderbare Welt von Isotopp »

server-key-injection is an SSH certificate issuer. A user connects with ssh -A, authenticates, and receives a new, short-lived keypair and certificate in their existing ssh-agent. Production hosts trust the user CA and make their authorization decision locally.

It is also an experiment in software development with a language model. No line of code outside /developer was written by a human. The source tree, tests, configuration, installer, and documentation were generated by an LLM in a code-generation harness. I wrote, reviewed, and repeatedly revised the requirements and their specialised derivatives.

That was the whole point of the exercise: The project is as much a proof of concept for SSH key injection as it is a test of a development process.

More precisely, I wanted to answer three questions:

  1. Can I develop a systematic vibecoding workflow, rather than merely have a sequence of lucky chat sessions?
  2. What code quality does that workflow actually produce?
  3. What teachable rules and background explain why the workflow functions when it does?

The answer to the first question is the specialization workflow below. The second is not answered by aesthetic preference alone: the code must be readable, the test suite must establish useful behavioural boundaries, and the result must survive implementation, security, and refactoring reviews. The third is the useful part, because a workflow which cannot be explained cannot be reliably repeated or improved.

The specialization workflow treats the model as a fallible implementation resource needing oversight, and tries to work from a lose discussion about a piece of software to hard requirements with mechanistic verification, with an intermediate step of a disposable “tracer” implementation verifying viability of the concept and tools. Using git and fresh contexts we have recovery points if at one step the entire codebase goes left. We anticipate that several feature-generation steps will accumulate cruft and pause in regular intervals for cleanup steps.

Requirements first

The central artifact is developer/architecture.md . It attempts to describe the system before code exists:

  • why the issuer exists and how the credential flow works;
  • the CLI surface and the user experience;
  • components, trust boundaries, and the production-host decision path;
  • the replaceable identity-provider boundary; and
  • the required security properties.

This is not a broad technical vision document. It is a deliberately concrete description of the desired behaviour. It says which key is long-lived, which key is ephemeral, where group membership is captured, what a target host may trust, what it must decide locally, and what must never be logged or persisted.

Writing this resembles the work of a product owner or technical program manager: progressively remove ambiguity until a later implementer has little room to choose an incompatible solution. Here the implementer happens to be a model.

The effect is incremental removal of degrees of freedom. I call the result a specialization workflow. A broad goal such as “issue short-lived SSH keys” does not constrain much. An architecture with exact principals, validity periods, trust boundaries, filesystem rules, and error behaviour constrains a great deal more. A user story constrains it further. A ticket should leave a small, testable change.

The disposable tracer

The first epic was intentionally throwaway: developer/2026-08-20-dummy-issuer-and-agent-injection-tracer . It proved the hard and unfamiliar part first: AsyncSSH can accept an ssh -A connection, reach the forwarded agent, inject a short-lived, non-functional certificate identity, and make it visible with ssh-add -l.

The test CA was disposable. No production host trusted it. The credential had a one-hour, test-only lifetime. There was no persistent CA state, no user database, no TOTP, no production authorization, and no useful login. It was a tracer: evidence that the wire-level construction was possible.

That tracer was later scrapped. Its value was not the code; it was the reduction of uncertainty: We proved that the protocol could do what we wanted, that the libraries chosen implement the functionality and that the problem in general was solvable with a model.

Once that we done we could (and did) scrap that code.

From epics to code

The architecture defines epics. Each one became a dated directory under developer/, such as developer/2026-08-21-persistent-ca-and-ordinary-certificate-issuance . That directory first received structured user-stories.md. Those stories were then developed into ordered, actionable tickets.md. Only then were tickets turned into tests and code.

The repository’s AGENTS.md contains the workflow verbatim:

## Specialization workflow

We never generate code ad hoc unless the user specifically requests it. A
direct request is a scoped bypass for debugging, an ad-hoc fix, or an
experiment; Git provides the recovery path for that work.

Otherwise, follow this directory-based workflow for the epic currently being
worked on. Do not modify artifacts belonging to another independent epic or
user story.

1. **User-story step.** Create a directory named
 `developer/<YYYY-MM-DD>-<epic-slug>/`. Put the epic's structured user stories
 in `user-stories.md` and any relevant reviews in that directory, for example
 `security-review.md` or `refactoring-review.md`.
2. **Ticket step.** Commit the current epic's relevant user-story or review
 file before this step. Develop it into actionable tickets in `tickets.md` in
 the same directory, ordered for implementation. Use the TDD skill while
 developing tickets.
3. **Code-generation step.** Commit that epic's `tickets.md` before beginning
 this step. Generate code from the tickets using the TDD skill. When a ticket
 is complete, commit it using the git-commit skill; only then proceed to the
 next ticket.

Committing between stages is useful. It makes the upstream decision durable, visible, and independently reviewable. It also gives the next context a stable starting point instead of a mixture of mutable prose, provisional tickets, and unfinished code.

The stages do not have equal safety properties. Tests gate the last stage mechanically. The architecture, stories, and tickets are primarily manual deliverables. That is where active, sometimes aggressive editing matters. Generating plausible but wrong tickets is a common symptom of an ambiguous architecture or user-story file, not a reason to patch around the problem in code. Delete the bad ticket file, fix the upstream requirement, start a fresh context, and regenerate it.

A harness, not a chat window

This does not work as a conversation pasted into a generic chat interface. The model needs a code-generation harness such as Codex or OpenCode. The harness gives it a Git repository, a shell, tests, and files it can create and read.

Those files are the project’s long-term memory. The model context is working memory: useful for the task in flight, but limited and disposable. The repository contains the durable decisions needed when the working context has ended.

The harness also enables progressive discovery. A model should not be given the entire repository, which is how one gets a large and contradictory context. It should discover the relevant context by reading index files and task-local guidance. A good index is a table or list of filenames with two or three sentences explaining what each file contains and when it should be read. README.md and AGENTS.md are particularly useful names because they make the index discoverable before the model has learned the project layout.

There are two complementary forms of context building:

  • Automatic context building is progressive discovery: the model reads the repository guides, follows their references, and loads what the current task needs.
  • Manual context building is a human deliberately asking the model to read certain files, discussing the result, and only then authorizing a modification.

The second is why it is better to develop architecture.md in dialogue with the model than to write it alone and ask for a later implementation. The discussion preloads the relevant context and directs attention to the constraints which matter.

Context management has a cost. Resetting a tainted context discards useful implicit rationale together with the contradiction. The answer is not to keep an ever larger transcript. It is to promote the rationale which must survive into concise, discoverable files, and to make a fresh context read those files before it acts. Context management for long-horizon software agents is an active engineering problem, not merely a prompt-writing detail; see Context as a Tool .

Architecture Decision Records are sometimes useful for recording a narrow, local choice. Their usefulness is limited, though: They help to keep the model on track, and prevent it from quietly reversing an earlier decision. They make automatic reconstruction of necessary context and decision history possible when starting a fresh new context.

architecture.md is different: it is the durable description of how we build the system – and what we build in the first place: constraints, and direction.

Skills and TDD

The project keeps skill guides in .agents/skills. They are part of the repository, both as documentation and so every contributor uses the same instructions. The essential one here is the Matt Pocock TDD skill.

It changes the code-generation step from “write something that sounds right” to a red-green-refactor loop:

  1. Decide the behavioural boundary.
  2. Write a test that demonstrates the missing behaviour.
  3. Lock the test in place.
  4. Write the smallest public implementation which makes it pass.
  5. Refactor only while the test stays green.

This does not prove the design correct. It does make a substantial class of regressions mechanically visible, and it forces the model to identify an observable contract before it reaches for implementation detail. The same repository guidance requires formatting, linting, type checking, and the test suite before handoff. This is also the core of the code-quality evaluation: manual review decides whether the requirements are the right ones, while the mechanical gates decide whether later changes continue to meet them.

The tests must include the boundaries which are too important to model only with units. For this project that means targeted integration evidence around the forwarded agent, the real sshd certificate path, target-host policy, file ownership, and the Rocky/SELinux environment. A unit test can establish that an adapter was called; it cannot prove that a production OpenSSH server accepts the right certificate and rejects the wrong one. Targeted non-unit tests and repeatable VM checks are where those claims belong.

Model choice and cost

Different stages benefit from different models. For the architecture and user-story stages I used ChatGPT-5.6/Sol at medium or high reasoning effort. The output was useful, but needed several interactive passes and substantial editing. That is the right place to spend attention, because errors multiply as requirements specialize downstream.

Ticket generation can use ChatGPT-5.6/Terra at medium or high reasoning. With good upstream documents, tickets usually need reading more than editing. Code generation used ChatGPT/Luna at xhigh: fast, very capable at the constrained task, and remarkably cheap.

The whole project consumed part of a weekly allowance from a monthly USD 20 ChatGPT subscription. Roughly USD 2.50 was attributable to this project. Around two thirds of that was spent on the larger models for architecture and stories; almost none was spent on generation of the code itself.

That ratio makes sense. Cheap code generation is valuable only after the problem is narrowly enough stated that cheap code generation has few damaging choices available.

Context is an engineering concern

Models produce worse work when the context is too large, when required facts are hidden on disk, or when it contains contradictory statements: “do this” next to “never do this”. I call the last condition tainted context.

Do not argue indefinitely with tainted context. Drop it. Start a new task or thread, preload the relevant files, ask for discussion rather than file generation, and issue the implementation request only once the model has seen the decisions which constrain it. This is not ritual; it is input hygiene.

The same discipline applies after several epics. Cruft accumulates even when tests pass. Every three to five epics, run a refactoring review, security review, test-quality review, or another appropriately scoped review. Select which findings to accept, cut scope deliberately, turn accepted findings into tickets, and run the same specialization workflow again.

One particularly useful form is an Adversarial Review. Give it to a fresh model context, or to a human who did not generate the change, and ask it to find evidence that the implementation, tickets, or tests are wrong. Do not ask the original generation context to approve its own reasoning; it is biased toward its framing and its omissions.

Test review deserves the same adversarial treatment. Read the tests; then review the tests, separately from the implementation. Ask specifically for tests which do nothing: tests with no meaningful assertion, tests which only prove that a called function received its parameters, tests which only exercise a mock, or tests which merely duplicate an implementation detail. They add maintenance cost and can be dropped.

Also ask which tests would survive unchanged under a plausible internal refactor. Those probably test a useful observable behaviour at the right seam. The aim is not a larger test count; it is tests which make the intended public contract harder to break. A focused request works: “Review these tests. Good looks like tests which observe a behavioural boundary, do not merely inspect parameter passing, and survive an internal refactor unchanged.” “Review this” is too vague for a model to apply a useful standard.

I am satisfied with the result. The code is not shaped as I would have written it by hand, but it is readable, fairly clean, and surrounded by tests. It has also been through refactoring and security review, and their accepted findings were fed back through the same story-ticket-code loop. A test review and the final epic are pending.

That is not a claim that the result is perfect. It is evidence that the workflow can produce code whose quality is inspectable, testable, and subject to ordinary engineering correction.

The teachable rules are equally ordinary: specialize requirements to remove degrees of freedom, make durable decisions discoverable on disk, use mechanical gates wherever the deliverable permits them, and discard tainted context instead of building on it.

This is not autonomous software engineering, and that is intentional. Models are probably not good at autonomous engineering yet, especially not for security-relevant work. During this project I had to limit scope and nip baroque architectures in the bud several times; models are particularly bad at YAGNI. A human still chooses the goal, the threat model, the acceptable risk, and the point at which a clever construction is simply too much construction.

We also have to read the tests and review the tests. An adversarial test review is not optional decoration around green CI. It asks whether tests assert useful behaviour, whether targeted non-unit checks cover the real boundaries, and whether apparently comprehensive tests are only checking that mocks received parameters. Focus the review: do not tell a model “Review this.” Tell it what good looks like, including tests which survive refactoring unchanged and tests which exercise the right seam. The process is not “ask an LLM to write a program.” It is to progressively remove degrees of freedom until a model can safely do a small, well-defined piece of engineering.

Sources

Top

Reading the ski SSH certificate issuer

Post by Kristian Köhntopp via Die wunderbare Welt von Isotopp »

ski is a small SSH certificate issuer. A user logs in to it, completes a password-and-TOTP exchange, and receives a new Ed25519 keypair plus a signed OpenSSH user certificate in their forwarded ssh-agent.

The code does not implement its own crypto or mechanism. It uses existing facilities of the OpenSSH protocol stack, and the proven AsyncSSH python library.

We will look at the code in detail in a few critical places: load a CA safely, authenticate an identity, turn its groups into principals, sign a new key, then inject the result into the agent.

The previous article demonstrates how to operate the thing and what that looks like. This one is a code tour.

CA

ski ca init enters through initialize_ca() in src/ski/ca_commands.py . It delegates file creation to CAFileWriter, then records the public key, fingerprint, and active state in SQLite.

The key generation itself is plain AsyncSSH:

207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
def _generate(self) -> GeneratedCAMaterial:
 try:
 key = self._key_generator()
 if key.get_algorithm() != "ssh-ed25519":
 raise CAFileError("CA algorithm is unsupported")
 private_bytes = key.export_private_key()
 public_bytes = key.export_public_key()
 except CAFileError:
 raise
 except Exception as exc:
 raise CAFileError("CA key generation failed") from exc
 return GeneratedCAMaterial(
 private_key=key,
 private_bytes=private_bytes,
 public_bytes=public_bytes,
 fingerprint=key.get_fingerprint(),
 )

CAFileWriter.install() writes private, public, and KRL files via temporary files and atomic renames. At startup, load_validated_active_ca() in src/ski/ca.py checks ownership and modes, imports both key files, checks that they match, then checks them against the active CA database record. Only then does the runtime receive a ValidatedActiveCA containing an AsyncSSH private-key object capable of signing.

That last point matters: most of the issuer sees a validated object, not a path to a magic key file.

SSH authentication

AsyncSSH provides the SSH server framework. IssuerServer.start() creates an AsyncSSH listener with agent_forwarding=True; _IssuerSSHServer implements the server-side authentication callbacks. It offers exactly one keyboard-interactive exchange with a password and a TOTP prompt.

After receiving the answers, validate_kbdint_response() does the meaningful work:

140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
try:
 canonical_username = self._identity_store.lookup_identity(username)
 password_ok = self._identity_store.verify_password(
 canonical_username,
 responses[0],
 )
 totp_ok = self._identity_store.verify_totp(
 canonical_username,
 responses[1],
 now=int(self._clock()),
 )
 if not password_ok or not totp_ok:
 if self._connection is not None:
 self._connection.abort()
 return False
 self._authenticated_identity = self._identity_store.get_group_snapshot(
 canonical_username,
 )
 return True

The server canonicalizes the username from the SSH banner and input by looking it up in the identity store. It then verifies both the password and TOTP factor. The group set assigned to the user is captured as a group snapshot. This becomes the input to issuance, that is, the creation key and cert.

We do, in theory, support pluggable identification backends, and provide only one demo backend using an SQLite database. How that works is discussed below, the important functions being called are available in identities.py:368, verify_password() and identities.py:402, verify_totp(). We are using pyotp for this job:

402
403
404
405
406
407
408
409
410
411
412
413
 def verify_totp(self, username: str, code: str, *, now: int | None = None) -> bool:
 try:
 record = self.get_user(username)
 if not record.enabled or not isinstance(code, str):
 return False
 totp = pyotp.TOTP(record.totp_secret)
 if self._totp_verifier is not None:
 return bool(self._totp_verifier(totp, code, now=now))
 for_time = None if now is None else datetime.fromtimestamp(now, tz=UTC)
 return bool(totp.verify(code, valid_window=1, for_time=for_time))
 except (IdentityStoreError, ValueError, TypeError):
 return False

In order to succeed, we do need a session with agent-forwarding to be able to inject the generated cert. That is why the session implementation, _IssuerSession._run_request() in src/ski/server.py , also rejects the request if AsyncSSH reports no forwarded agent path. No point in running an issuance with no delivery channel.

Identity abstraction

The SSH server depends on this deliberately small protocol, not on SQLite:

123
124
125
126
127
128
129
class IssuerIdentityProvider(
 IdentityAuthenticator,
 CanonicalIdentityLookup,
 GroupSnapshotProvider,
 Protocol,
):
 """Combined narrow read-only capability required by the SSH issuer."""

The three parent protocols are the contract: canonical lookup, verification of the two existing factors, and a current group snapshot. It is a good boundary for a production adapter backed by LDAP, Active Directory, Keycloak, Okta, or another organisation-specific identity service and contains no write-operations.

The current demonstrator does not use any of that so it can be self-contained. ServiceRuntime.start() constructs SqliteIdentityStore directly. Its get_group_snapshot() reads the local record, rejects disabled users, and returns the username plus groups. The ski user and ski group commands exist to administer that demo backend. They should not be part of a production issuer: identity and group management belongs in the upstream identity system, and the issuer should be read-only with respect to it.

Principal construction

The certificate receives a structured identity record.

build_principals() in src/ski/policy.py accepts only canonical values and produces a compact, predictable principal set:

47
48
49
50
51
52
def build_principals(username: object, groups: Sequence[object]) -> tuple[str, ...]:
 """Build the canonical user and group principals for one identity."""
 canonical_username = validate_username(username)
 canonical_groups = tuple(validate_group_name(group) for group in groups)
 principals = (canonical_username, *(f"group:{group}" for group in canonical_groups))
 return validate_principals(principals)

For kris in prod, this produces ("kris", "group:prod"). The first principal can support self-login policy; subsequent group: principals let a target host make local group-based authorization decisions. The grammar and duplicate checks prevent principals from becoming an accidental free-form authorization language.

Signing

OrdinaryCertificateFactory.issue() in src/ski/credentials.py is the centre of the issuer. It allocates a random 64-bit serial, sets the fixed 25-hour validity window, creates a fresh user key, and invokes the CA private key:

 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
serial = self._serial_allocator()
if not isinstance(serial, int) or not 0 <= serial < 2**64:
 raise StateError("certificate serial is malformed")
valid_after = int(self._clock())
valid_before = valid_after + ORDINARY_CERTIFICATE_LIFETIME
comment = (
 f"ski:{identity.username}:{self._active_ca.record.fingerprint}:{serial}"
)
private_key = asyncssh.generate_private_key(
 "ssh-ed25519",
 comment=comment,
)
flags = {
 flag: extension in self._extensions
 for extension, flag in ORDINARY_EXTENSION_FLAGS.items()
}
certificate = self._active_ca.private_key.generate_user_certificate(
 private_key,
 identity.username,
 serial=serial,
 principals=principals,
 valid_after=valid_after,
 valid_before=valid_before,
 permit_x11_forwarding=flags["permit_x11_forwarding"],
 permit_agent_forwarding=flags["permit_agent_forwarding"],
 permit_port_forwarding=flags["permit_port_forwarding"],
 permit_pty=flags["permit_pty"],
 permit_user_rc=flags["permit_user_rc"],
 touch_required=True,
 comment=comment,
)

Again, we make use of AsyncSSH library functions for certficiate handling: generate_user_certificate() does the OpenSSH certificate signing. Its first argument is the new user key, it contains both the private and public bytes; AsyncSSH uses only the public half. The remaining arguments become the certificate’s claims and restrictions. The configured extensions are converted into explicit OpenSSH permit flags instead of being copied as arbitrary text.

OrdinaryIssuanceService.commit() persists only safe issuance evidence: serial, identity, public-key fingerprint, principals, validity period, and request ID.

It does not persist the ephemeral private key.

Injection

Signing has produced Python objects; it has not yet delivered anything to the user. OrdinaryAgentInjector.handle() connects to the agent forwarded by the current AsyncSSH server connection, removes only an earlier credential it can recognize as its own, and then loads the new pair:

190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
async with self._agent_factory(connection, self._active_ca) as agent:
 owned = await agent.owned_keys(identity)
 removed_owned = False
 credential: OrdinaryIdentity | None = None
 try:
 for _ in range(5):
 credential = self._issuance.prepare(identity)
 lifetime = max(
 1,
 credential.valid_before - int(self._clock()),
 )
 if owned and not removed_owned:
 await agent.remove_keys(owned)
 removed_owned = True
 await agent.add_credential(credential, lifetime=lifetime)
 try:
 record = self._issuance.commit(
 credential,
 request_id=request_id,
 )
 except DuplicateCertificateSerialError:
 cleanup = await agent.remove_credential(credential)
 if not cleanup.complete:
 raise StateError("credential cleanup failed")
 continue
 return OrdinaryInjectionResult(
 credential=credential,
 record=record,
 groups=identity.groups,
 )

The adapter behind agent uses asyncssh.connect_agent(connection). AsyncSSH opens the forwarded-agent connection and speaks the OpenSSH agent protocol; the application code works with keys and certificates instead of framing agent-protocol messages itself.

The ordering is worth noticing. The new credential is first added with a lifetime no later than certificate expiry, then durable issuance evidence is committed. A duplicate serial triggers targeted agent cleanup and a retry; other failures also attempt cleanup. That is the small but important piece which prevents an in-memory credential from silently surviving a failed issuance transaction.

The whole issuer is therefore ordinary Python around a few AsyncSSH boundary calls: generate a private key, sign a user certificate, operate the forwarded agent. The surrounding code establishes what those calls are allowed to mean.

Top

Installing the ephemeral SSH key demonstrator

Post by Kristian Köhntopp via Die wunderbare Welt von Isotopp »

The previous article explained ephemeral SSH keys. This is the concrete demonstrator: a Mac runs the certificate issuer, a Rocky Linux VM is the production host, and a normal ssh login uses a one-day certificate held only in the Mac’s ssh-agent.

Mac: issuer Rocky Linux: target host
──────────────────────────────────────────── ─────────────────────────────────────
ski serve sshd
 ├── user CA private key ├── public user-CA key
 ├── local identity and group data ├── local authorization.toml
 └── issues a short-lived certificate └── ski-authorize helper
 │ ▲
 │ agent forwarding during issuance │ certificate login
 ▼ │
 ssh-agent on the Mac ─────────────────────────────────────────┘
 ephemeral private key + certificate

The CA private key, issuer database, and user private key remain on the Mac. The Rocky VM receives only the CA public key and its own local authorization policy. Its login path does not contact the issuer.

This is a demonstrator, not a production deployment guide. In a real setup, verify host keys through a trusted channel, protect the issuer’s CA key, and deploy target-host files with configuration management.

More importantly, the issuer’s SQLite database is demonstrator scaffolding, not a production identity source. A real issuer would read canonical users and group memberships from the organisation’s identity backend: for example LDAP, Active Directory, Keycloak, or Okta. User creation, passwords, second factors, and group administration remain the responsibility of that backend. The issuer is read-only with respect to identity data: after authenticating a request and reading a current group snapshot, it issues a certificate. It does not manage users or mutate group membership through ski commands.

1. Prepare the issuer on macOS

The checkout on the Mac is ~/PycharmProjects/ski and its dependencies are locked through uv:

~ $ cd PycharmProjects
PycharmProjects $ git clone https://github.com/isotopp/server-key-injection/ ski
PycharmProjects $ cd ski/
ski $ ls
AGENTS.md README.md
developer docs
packages pyproject.toml
src tests
uv.lock

The local .env selects paths. It contains no secret material: the private CA key is a file at the named path, not a value in the environment file.

SKI_CA_DATABASE=ski.sqlite3
SKI_CA_PRIVATE_KEY=etc/keys/user_ca
SKI_CA_PUBLIC_KEY=etc/keys/user_ca.pub
SKI_CA_KRL=etc/keys/revoked.krl
ORDINARY_CERT_EXTENSIONS=pty

ORDINARY_CERT_EXTENSIONS=pty deliberately grants a terminal but not agent, TCP, or X11 forwarding to the resulting production login. Agent forwarding is needed only for the brief connection to the issuer, to put the new credential in the workstation’s agent.

2. Create the user CA

Initialize a User CA once. This generates an Ed25519 CA keypair and records its state in the configured database:

ski $ mkdir -p etc/keys
ski $ uv run ski ca init
CA initialized.
Algorithm: ssh-ed25519
Fingerprint: SHA256:r2+zadY0Ln3LQiNrCFxNY5aVVqSFuuDtCDEwc5itj+Q
CA committed, but service notification failed; retry notification.
ski: CA initialized; service notification failed; retry notification

ski $ uv run ski ca show
CA ID: 1
Algorithm: ssh-ed25519
Fingerprint: SHA256:r2+zadY0Ln3LQiNrCFxNY5aVVqSFuuDtCDEwc5itj+Q
Status: active
Activated: 1787422938

ski $ uv run ski ca public-key
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILGt49Riwdjygm6Okt1Uvd9ldgNaFRrpb8OZhyCktJQR

There is no running issuer yet, so the service-notification warning is expected. Keep both values. The target policy pins the CA by fingerprint; user-ca.pub is the public verification key given to sshd. Neither is secret. The private CA key in etc/keys/user_ca must never leave the issuer.

3. Create a user and group

Create kris and make it a member of prod:

ski $ uv run ski user add kris
Password:
User created: kris
TOTP secret: <redacted>
TOTP URI: otpauth://totp/ski:kris?secret=<redacted>&issuer=ski
ski: service notification failed; mutation committed; retry notification

ski $ uv run ski group add prod
Group created: prod
ski: service notification failed; mutation committed; retry notification

ski $ uv run ski group member add prod kris
Membership added: prod kris
ski: service notification failed; mutation committed; retry notification

Those notifications also have nowhere to go until ski serve starts. Password and TOTP authenticate the issuance request. The outcome is a certificate with the signed principal group:prod; the password is not used on the target host.

For this demonstrator, we added the TOTP secret into a TOTP generator such as bitwarden. Another way to work with this is to use oath-toolkit:

$ brew install oath-toolkit
$ oathtool -b <redacted>
459274

4. Start the issuer and obtain a certificate

Run the issuer in one terminal:

ski $ uv run ski serve --port 2222
service_starting: ski startup requested
service_ready: ski is ready

In another terminal, ensure a local ssh-agent exists, then forward it only to this trusted local issuer:

ski $ ssh -A -tt -p 2222 \
 -o StrictHostKeyChecking=no \
 -o UserKnownHostsFile=/dev/null \
 kris@127.0.0.1
Warning: Permanently added '[127.0.0.1]:2222' (ED25519) to the list of known hosts.
ski
Authenticate with your ski password and TOTP code.
(kris@127.0.0.1) Password:
(kris@127.0.0.1) 2FA:
Key loaded: kris serial=367065752294255925 valid-until=1787513156
Groups: prod
Connection to 127.0.0.1 closed.

The host-key options are acceptable only for this disposable loopback test: they disable SSH’s protection against connecting to the wrong server. A real issuer needs a verified known_hosts entry.

The issuer authenticates the user, generates a fresh keypair, signs the public key, and sends an add-identity request through the forwarded agent channel. It then closes the interactive connection. The local agent now shows one key and its certificate:

ski $ ssh-add -l
...
256 SHA256:uQLZAupxPTPBXhEMMWW6UzsH3JfFNIVS1Fl9xkOgg+U ski:kris:SHA256:r2+zadY0Ln3LQiNrCFxNY5aVVqSFuuDtCDEwc5itj+Q:367065752294255925 (ED25519-CERT)
256 SHA256:uQLZAupxPTPBXhEMMWW6UzsH3JfFNIVS1Fl9xkOgg+U ski:kris:SHA256:r2+zadY0Ln3LQiNrCFxNY5aVVqSFuuDtCDEwc5itj+Q:367065752294255925 (ED25519)

These are one credential, not two: the ED25519 entry is the ephemeral private key, while ED25519-CERT is its signed public certificate. They have the same fingerprint. Nothing new was written to ~/.ssh.

At this point the issuer and agent work. No target host has yet been taught to trust the certificate.

5. Install the target-host authorizer

The target is a Rocky Linux VM with a pre-existing local Unix account named kris. The authorizer does not create accounts or map the certificate to a different account. Check for OpenSSH 9 or later, then run the packaged installer as root from packages/ski-authorize:

[root@localhost ski-authorize]# git clone https://github.com/isotopp/server-key-injection/
...

[root@localhost ski-authorize]# cd server-key-injection
[root@localhost server-key-injection]# cd packages/ski-authorize
[root@localhost ski-authorize]# ./install.sh
Python 3.12 is already installed
Resolved 6 packages in 121ms
Building ski-authorize @ file:///root/server-key-injection/packages/ski-authorize
Prepared 1 package in 14ms
Installed 1 executable: ski-authorize
warning: `/opt/ski-authorize/bin` is not on your PATH.
ski-authorize installed below /opt/ski-authorize

The PATH warning is irrelevant: sshd invokes the helper by absolute path. The installation tree is root owned; the helper runs under an unprivileged ski-authz account (which was already created by the installer):

/opt/ski-authorize/
├── bin/ski-authorize
├── cache/
├── config/
│ ├── authorization.toml
│ └── user-ca.pub
├── python/
└── tools/

Transfer only the public CA key from the Mac through a reviewed mechanism. Never transfer the private CA key, SQLite database, .env, or agent contents.

Put the output of uv run ski ca show and uv run ski ca public-key into the host’s local policy and verification-key file:

[ssh]
trusted_ca_fingerprint = "SHA256:r2+zadY0Ln3LQiNrCFxNY5aVVqSFuuDtCDEwc5itj+Q"
allowed_groups = [ "group:prod" ]
allow_self_login_only = true
[root@localhost config]# pwd
/opt/ski-authorize/config
[root@localhost config]# cat user-ca.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILGt49Riwdjygm6Okt1Uvd9ldgNaFRrpb8OZhyCktJQR
[root@localhost config]# ls -l
total 8
-rw-r-----. 1 root ski-authz 375 Aug 22 20:30 authorization.toml
-rw-r--r--. 1 root root 81 Aug 22 20:32 user-ca.pub

Compare the fingerprint using an independent channel before accepting it.

allow_self_login_only = true permits a certificate for kris only to log into local account kris (other configurations are not supported anyway at this point int time).

The group requirement adds group:prod to the host: Only users with group:prod in their certficate may log in.

6. Configure and reload sshd

The installer places this fragment in /etc/ssh/sshd_config.d:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
TrustedUserCAKeys /opt/ski-authorize/config/user-ca.pub
CASignatureAlgorithms ssh-ed25519
AuthorizedPrincipalsCommand /opt/ski-authorize/bin/ski-authorize --config /opt/ski-authorize/config/authorization.toml --ca-fingerprint %F %u %t %k
AuthorizedPrincipalsCommandUser ski-authz

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no

TrustedUserCAKeys names the CA allowed to sign user certificates. AuthorizedPrincipalsCommand receives the signing CA fingerprint (%F), requested local user (%u), certificate type (%t), and certificate body (%k). sshd verifies the cryptography; the helper applies the local policy. The forwarding directives constrain the production session, not the earlier connection to the issuer.

Validate the whole SSH configuration before reloading:

[root@localhost ~]# sshd -t
[root@localhost ~]# systemctl reload sshd
[root@localhost ~]# logout
flowchart TB
CERT["Certificate offered by client\nkey ID: kris\nprincipal: group:prod"] --> SSHD["Rocky sshd"]
CA["user-ca.pub"] --> SSHD
SSHD -->|"signature valid"| AUTHZ["ski-authorize\nrun as ski-authz"]
POLICY["authorization.toml\nCA fingerprint, group:prod,\nself-login only"] --> AUTHZ
AUTHZ -->|"principal kris allowed"| SSHD
SSHD --> SESSION["Unix session for kris"]

7. Login and inspect the evidence

The Mac SSH client discovers the certificate-backed key in its agent. No special IdentityFile is needed:

~ $ ssh 192.168.64.3 -l kris
Last login: Sat Aug 22 20:28:45 2026 from 192.168.64.1
[kris@localhost ~]$

The host log proves that this was certificate authentication:

[root@localhost log]# tail -4 /var/log/secure
Aug 22 20:35:20 localhost sshd-session[2152]: Accepted publickey for kris from 192.168.64.1 port 60378 ssh2: ED25519-CERT SHA256:yutOUApby5l70x4kxF1QYwXCnrygAWEVsZYiEmuoz+s ID kris (serial 9739375750096054870) CA ED25519 SHA256:r2+zadY0Ln3LQiNrCFxNY5aVVqSFuuDtCDEwc5itj+Q
Aug 22 20:35:20 localhost sshd-session[2152]: pam_unix(sshd:session): session opened for user kris(uid=1000) by kris(uid=0)

The useful evidence is ED25519-CERT, the key ID, serial, and CA fingerprint. The target verified a certificate signed by the expected CA and opened its local kris account. The issuer did not take part in this login.

8. Treat the SELinux AVC as a finding

The successful Rocky login also produced an AVC for ski-authorize trying to execute ldconfig from sshd_session_t. The helper still completed because native-library discovery has a fallback. That is not a reason to suppress the denial. Do not disable SELinux, run audit2allow. Fix packaging, runtime dependency discovery, and file labels so the helper works under its intended confinement.

The end state is deliberately small: the Mac agent contains a short-lived private key and certificate; the Rocky host accepts it only when its local CA and group policy agree. Once the agent entry or certificate expires, new logins stop until the user obtains a fresh credential from the issuer.

Top

Ephemeral SSH Keys

Post by Kristian Köhntopp via Die wunderbare Welt von Isotopp »

The SSH keys living in your $HOME/.ssh are practically immortal. You create id_ed25519 once, copy its public half to a target host and insert it into authorized_keys, and retain access for years. The private key lives on a laptop, in backups, and often on machines which have long since stopped being used.

That is convenient, but it makes for an unpleasant authorization model. When someone leaves the company or a team, every relevant host must be changed. If a laptop is lost, someone must know where its key is authorized. And authorized_keys becomes a distributed, hard-to-audit identity database.

A better separation is to stop having hosts trust every individual user key. Instead, they trust a small number of SSH certificate authorities (CAs). A CA issues an SSH certificate for a fresh, short-lived key. The certificate might be valid for only 25 hours. Its private key lives solely in ssh-agent and then disappears. It is never materialized on a developer’s laptop disk.

This is not a new SSH protocol. OpenSSH has supported it for a long time (since OpenSSH 8.8). The important part is understanding what the key, certificate, agent, and sshd each do.

Three things which are not the same

Classic public-key authentication has one key pair:

  • The private key stays with the user and produces signatures.
  • The public key lives in authorized_keys on the target host.

SSH certificates add a third object: the user certificate. It contains a public user key, a list of principals, a validity period, a serial number, and optional restrictions. An SSH CA signs this package with its private CA key.

The certificate is not secret. Nor is it a replacement for the private key. It merely says: “The holder of this public key may act as these principals between these times.” During login, the client must still prove that it holds the matching private key.

flowchart TB
CA["SSH user CA\nprivate CA key"] -->|"signs"| CERT["SSH user certificate\npublic key\nprincipals, expiry"]
KEY["ephemeral private\nuser key"] -->|"matches"| CERT
KEY -->|"proof-of-possession signature"| SSHD["sshd on the target host"]
CERT -->|"CA signature and policy"| SSHD
CAPUB["public CA key\non target host"] -->|"trust anchor"| SSHD

The central private CA key is especially sensitive: anyone who controls it can issue certificates. The temporary private user key is shorter lived, but it is still a real login secret for as long as it remains valid. It belongs neither in a Git repository nor a shell history nor permanently in ~/.ssh – and it usually isn’t, because we’ll put it into a developers agent, which will not let to go to a disk.

What ssh-agent actually does

ssh-agent is a process on the workstation. It keeps private keys in memory and exposes a Unix socket. The path to this socket is in SSH_AUTH_SOCK. Programs such as ssh, scp, and git talk to the agent instead of reading the key file themselves.

In this setup, the SSH client is never handed the private key. Instead it asks the agent: “Here are the authentication-protocol data; can you sign them with key X?” The agent returns the signature. This permits local passphrase prompts, hardware-backed keys, or a fixed lifetime without every SSH client needing to understand those details.

sequenceDiagram
participant C as ssh client
participant A as ssh-agent
participant S as target host:sshd
C->>A: Which public identities do you have?
A-->>C: Public keys and certificates
C->>S: Offer certificate and public key
S-->>C: This identity is allowed. Sign the session
C->>A: Sign the SSH session data with the matching key
A-->>C: Signature
C->>S: Signature
S-->>C: Login accepted

Normally, one loads a long-lived key into the agent with ssh-add.

In the model with ephemeral keys, a new key is generated by the remote issuer and tunneled into the agent through the local ssh client, together with its matching certificate. This ephemeral key and cert are given a lifetime.

ssh-add -l will then show both: an ED25519 entry and an ED25519-CERT entry.

$ ssh-add -l
...
256 SHA256:RquDquM94ouXwDMCo4uNdWiuGz1nwEzvX7Qmwev80QI ski:kris:SHA256:w6aQ5C02+aexz6g5eULg7TSO1piXyAD90+fy259e5fg:13861769879096579493 (ED25519-CERT)
256 SHA256:RquDquM94ouXwDMCo4uNdWiuGz1nwEzvX7Qmwev80QI ski:kris:SHA256:w6aQ5C02+aexz6g5eULg7TSO1piXyAD90+fy259e5fg:13861769879096579493 (ED25519)

These are not two independent credentials: the first is the private key, the second is its signed public certificate.

When the lifetime expires, the agent removes the identity. The private key is then no longer present. It can also be removed explicitly; ssh-add -D is often too broad because it removes every identity from the agent.

How the key reaches the agent

In our setup, we have the “issuer”, a server into which the user logs at the beginning of the work day.

The issuer verifies the user password and a TOTP 2FA challenge, then creates a fresh Ed25519 key pair with a 25h lifetime, the users user-principal and the set of groups the user is in, plus the capabilities of the key (agent forwarding, port forwarding and so on). It signs the public half with the user CA, and puts both into the workstation’s agent. It then closes the connection.

For the issuer to reach the local agent, the agent is deliberately forwarded to this one host:

ssh -A kris@ssh.example.com

This is what happens at the protocol level:

  1. The client sends an auth-agent-req@openssh.com request on the SSH session channel. This asks the remote sshd to make the forwarded agent available to this login session.
  2. sshd creates a Unix-domain listening socket owned by the logged-in user, sets SSH_AUTH_SOCK in that user’s session environment, and gives the process restrictive access to the socket.
  3. When a process on the issuer connects to that socket, sshd opens an auth-agent@openssh.com channel back to the client. It does not send a private key and it does not create a second agent on the server.
  4. The client connects to its local SSH_AUTH_SOCK and copies the byte stream between that socket and the auth-agent@openssh.com channel.

The result is a short-lived proxy. To an issuer process, the socket named by SSH_AUTH_SOCK looks like an ordinary local OpenSSH agent socket. The real agent, and the private keys already stored in it, stay on the workstation.

An agent socket transports the SSH agent protocol, not SSH packets. Individual messages are length-prefixed and start with a request or reply type. In this case, the issuer uses an add-identity request — normally the constrained form, SSH_AGENTC_ADD_ID_CONSTRAINED — containing the newly generated private key, the certificate associated with its public half, and a lifetime constraint. The exact message bytes cross the remote socket, the SSH channel, and the local socket before reaching the local agent unchanged. The reply follows the same route in reverse.

sequenceDiagram
participant A as workstation:ssh-agent
participant C as workstation:ssh -A
participant D as issuer:sshd
participant I as issuer process
C->>D: Session channel request: auth-agent-req@openssh.com
D-->>C: Request succeeds
Note over D: Create Unix socket and set SSH_AUTH_SOCK
D->>I: Start login session
I->>D: Connect to remote SSH_AUTH_SOCK
D->>C: Open auth-agent@openssh.com channel
C->>A: Connect to local SSH_AUTH_SOCK
I->>D: SSH_AGENTC_ADD_ID_CONSTRAINED message
D->>C: Agent-protocol bytes
C->>A: Same agent-protocol bytes
A-->>C: SSH_AGENT_SUCCESS
C-->>D: Agent-protocol reply
D-->>I: Reply from remote socket

The channel is opened for each connection to the remote socket. It is a stream proxy, so an issuer can first request identities, then request signatures, or add an identity. The forwarded connection ends when the socket connection or SSH session ends; the credential loaded into the local agent survives only for the lifetime set in the add-identity request.

This pattern has an important trust assumption: agent forwarding does not belong on arbitrary servers. Whoever may use a forwarded agent can request login signatures from its keys. In this case, the issuer may also add a new identity to the agent. That is the intended effect, but it is justifiable only for a particularly trusted, reviewed issuer.

The alternative — having the issuer return a private key as a file — is worse: it produces files, backups, and copies. Agent injection is no magic, but it limits the key to memory and a defined lifetime.

What the production host verifies

On a conventional host, an entry in ~/.ssh/authorized_keys means that one public key may log in as one local Unix account. Certificates move the trust anchor to the CA key:

TrustedUserCAKeys /etc/ssh/user-ca.pub

sshd can now verify an offered user certificate by itself:

  1. Is it really a user certificate, and does its public key match the key now proving possession?
  2. Is the signature valid under a configured CA key?
  3. Does the local clock fall between valid_after and valid_before?
  4. Does one of the certificate principals match the requested local login name or the local principal policy?
  5. Do critical options or a revocation list prevent login?

Cryptography therefore does not answer the whole question, “May Kris use this host?” It answers only: “A trusted CA issued this certificate for this key and these claims.” The host policy then decides whether any of those claims is sufficient here.

flowchart TD
OFFER["Client offers\nprivate key + certificate"] --> SIG{"Proof of possession\nvalid?"}
SIG -->|no| DENY["Deny login"]
SIG -->|yes| CA{"CA signature\ntrusted?"}
CA -->|no| DENY
CA -->|yes| TIME{"Certificate\nstill valid?"}
TIME -->|no| DENY
TIME -->|yes| POLICY{"Principal and local\nhost policy match?"}
POLICY -->|no| DENY
POLICY -->|yes| OK["Open session for\nlocal account"]

The local policy can be simple: the kris principal may use the kris Unix account. It may also use groups as principals, such as group:prod. An AuthorizedPrincipalsCommand can then compare a certificate’s signed group against a local, root-protected policy to decide whether that group grants access on this host. The host need not query the issuer, LDAP, Okta, or any other identity service.

The AuthorizedPrincipalsCommand does not need to run as root or the ssh user, and in fact it should not. It also does not need to own any files at all, so it can’t overwrite anything. All communication is through pipelines and command line parameters.

That is operationally useful. The production host needs only the public CA key and its local policy. There may even deliberately be no route from the production network to the issuer. The user carries their fresh, signed certificate across the firewall.

Short lifetime is the revocation strategy

A certificate with a 25-hour lifetime has a clear disadvantage: if someone is removed from a group at 09:00, a certificate issued at 08:59 may still open new sessions until it expires. The agent cannot “recall” a certificate merely because central group membership has changed.

This is not a bug; it follows from hosts operating offline. The maximum remaining lifetime is the deliberately chosen risk window. Shorter certificates reduce it, but require renewal more often. Additional Key Revocation Lists (KRLs) can invalidate individual certificates early, but must then be reliably distributed to every host too.

Time synchronization and an explicit lifetime policy are therefore security features. A 25-hour period can cover a working day and the next morning’s renewal window; other environments may use four hours, one shift, or a few minutes. “Short” is not a cryptographic property. It is a trade-off between operations and the exposure window.

What this improves — and what it does not

Ephemeral SSH keys reduce the lifetime of a compromisable user secret and replace a large collection of distributed authorized_keys entries with a few CA trust anchors. Group and authorization changes take effect at the next issuance, without every host having to make a central query at login.

They do not replace normal SSH fundamentals:

  • The workstation must still verify the issuer’s host key. A user CA is not the issuer’s host key.
  • The private CA key needs much stronger protection than an ordinary user key.
  • Agent forwarding is a powerful capability and must be targeted only at trusted issuers.
  • Target hosts must correctly manage their public CA key, local policy, and clock.

The model does not remove trust; it makes it visible: in a small CA, a tightly bounded issuer, the local agent, and an explicit policy on every target host. The user still works with ordinary ssh. Only the key used to identify them has a short, intentionally ephemeral life.

This description is based on the architecture and operational documentation of server-key-injection .

Top

FreeBSD 14.5-BETA3 Available

Post by FreeBSD Newsflash via FreeBSD News Flash »

The third BETA build for the FreeBSD 14.5 release cycle is now available. ISO images for the amd64, i386, armv7, aarch64, powerpc, powerpcspe, powerpc64, powerpc64le, and riscv64 architectures are FreeBSD mirror sites.
Top

FreeBSD Foundation Intern Jim Huang Chen on Raspberry Pi Support and Open Source

Post by FreeBSD Foundation via FreeBSD Foundation »

When Jim Huang Chen began his internship with the FreeBSD Foundation, he was only finishing his first year as a Software Engineering student at the University of Waterloo. A few months later, he had spent the summer working inside the FreeBSD codebase, contributing to Raspberry Pi support, learning from longtime developers, and gaining a much deeper understanding of how an operating system works.

For Jim, that process of learning became one of the most valuable parts of the experience.

From a Graphing Calculator to Systems Programming

Jim’s interest in programming started well before university.

Around seventh grade, he began programming simple games on a TI-84 graphing calculator using TI-BASIC. That eventually led him to the Cemetech community, where he connected with other technology enthusiasts and started exploring lower-level languages, including assembly and C.

Throughout high school, Jim frequently worked with older hardware that he didn’t want to purchase Windows licenses for. Linux became the natural alternative, introducing him more deeply to open source software and the communities surrounding it.

“Systems programming is about as close as you can get to treating computers as a machine rather than magical software abstractions,” Jim said.

That perspective appealed to his interests in mathematics, computation, and understanding what computers are actually doing beneath the software we interact with every day.

Taking a Chance on FreeBSD

Jim originally expected to pursue Google Summer of Code and didn’t know that the FreeBSD Foundation offered an internship program.

That changed when he came across the opportunity on WaterlooWorks, the University of Waterloo’s job board.

With hundreds of other applicants, he wasn’t particularly confident about his chances. But the work interested him enough to apply anyway.

“I figured I might as well write a cover letter, submit my resume, and pray,” he said. “I’m glad it worked out!”

That application led to a summer focused primarily on two Raspberry Pi projects.

Expanding FreeBSD Support for Raspberry Pi

Jim’s first project involved porting Raspberry Pi Imager to FreeBSD.

Raspberry Pi Imager provides a graphical way for users to prepare a Raspberry Pi, including selecting a device, choosing an operating system image, configuring settings, and writing the image to storage.

Before Jim’s work, the application supported Linux, macOS, and Windows, but not FreeBSD natively.

His task was to add a FreeBSD backend using FreeBSD-specific libraries and functionality. The goal was to make a native version available through the FreeBSD Ports Collection rather than relying on another operating system’s version through a compatibility layer. The resulting changes are currently under review for inclusion upstream.

His second project took him even deeper into hardware: bringing FreeBSD support to the Raspberry Pi Compute Module 5.

That work required adding support for components including the Raspberry Pi 5’s PCIe controller and RP1 southbridge, which manages access to peripherals such as Ethernet and USB.

By the time Jim reflected on the project, he was confident that the PCIe controller was working, while memory allocation for devices connected through the RP1 remained an ongoing challenge.

Learning to Understand the “Why”

For Jim, the biggest reward wasn’t one patch or technical milestone.

It was being able to look back and see how much more he understood.

As a first-year student entering a large operating system codebase, there were inevitably pieces that initially didn’t make sense. Over the course of the internship, reading code, writing code, studying documentation, and asking questions gradually changed that.

He reached a point where he could not only explain what his code was doing, but why it needed to be there.

That growth also changed some of his assumptions about FreeBSD.

Before the internship, Jim viewed FreeBSD largely as an operating system for a relatively stable world of amd64 servers. Working with arm64 showed him how much development is happening underneath FreeBSD’s consistent user-facing experience.

He encountered evolving interrupt and clock frameworks, different approaches to device enumeration, and interfaces that have changed considerably over the Project’s history.

“Just taking time to explore how much is boiling in the code under the always-calm, always-consistent user-accessible surface of the operating system has been pretty amazing,” he said.

Finding the Problem Before Finding the Solution

One of the most important lessons Jim learned was that solving a technical problem often starts with figuring out exactly what the problem is.

For the Raspberry Pi Imager work, FreeBSD’s documentation gave him a strong starting point. Man pages, the FreeBSD Handbook, existing scripts, and other resources helped him gradually understand FreeBSD’s disk architecture.

The Raspberry Pi Compute Module 5 was more difficult.

Because components such as Broadcom’s BCM2712 and Raspberry Pi’s RP1 are relatively new, detailed technical documentation could be difficult to find. Jim supplemented what was available by reading about driver development, studying similar drivers, and asking experienced developers for guidance.

“More often than not, it’s easier to ask someone why something needs to be done than to wizard out the intention from the code they write,” he said.

He also learned to make his development process more efficient.

Early in the internship, rebuilding the FreeBSD kernel locally could take minutes for an incremental build and hours for a clean build. Moving compilation to the Foundation’s build servers reduced those waits significantly.

Jim then automated repetitive steps in his workflow, including building, booting the Raspberry Pi, mounting disks, copying files, and unmounting them.

Those improvements did more than save time. They made experimentation easier and gave him more room to focus on understanding the underlying technical problems.

 

Meeting the Community Behind the Code

Jim also attended BSDCan and the FreeBSD Developer Summit during his internship.

Initially, the experience was intimidating.

Only about a month into the internship, Jim found himself surrounded by people who had been developing and using FreeBSD for decades. But that feeling changed as he began talking with community members.

“If you have something to talk about, it’s more likely than not that someone will be excited to talk you through it and discuss whatever you had on your mind,” he said.

He attended sessions covering topics ranging from security and capability pointers to static analysis, formal verification, hardware support, and the future of FreeBSD’s scheduler.

What surprised him most was how social the events were. Rather than simply listening to presentations, much of the value came from discussions, questions, feedback, and conversations with other attendees.

“Definitely much more immersive than the 9-5 university-style lectures I anticipated.”

Making Open Source Feel More Accessible

Working directly with the FreeBSD community also changed Jim’s perception of contributing to open source.

From the outside, large projects can sometimes appear intimidating or reserved for highly experienced developers. His experience with FreeBSD was different.

“The people are nice,” he said. “They are willing to give you mentorship and to give some thought to patches you submit.”

The internship also gave him a greater appreciation for the broader open source ecosystem and how much software depends on projects maintained by relatively small groups of contributors.

For Jim, that highlighted both the importance of open source and the need for more people to contribute their time, expertise, and support.

His Advice: Start the Conversation

Jim’s advice for students thinking about contributing to FreeBSD is straightforward: reach out.

“I think that if you’re thinking about getting involved yourself, you should really bite the bullet and email someone involved in the project.”

Using FreeBSD itself can also reveal opportunities to contribute. If something doesn’t work as expected, investigating why could lead to a first bug fix or patch.

For those interested in a particular area, Jim recommends looking through development activity to find the people working on that part of the system and asking where help is needed.

The important part is starting somewhere.

Plenty More to Explore

Jim doesn’t plan for his FreeBSD work to end with the internship.

He hopes to continue improving Raspberry Pi 5 and RP1 support, create ports for software he would like to use on FreeBSD, and investigate issues he has encountered while running FreeBSD on his own hardware.

He is also interested in eventually exploring the FreeBSD network stack, scheduling, and resource management.

As for his career, Jim is still early in his studies and keeping his options open, but systems programming and formal methods are areas he would like to continue exploring.

A Summer of Exploration

Jim credits Ed Maste and Siva Mahadevan for giving him the opportunity and supporting him throughout the internship. He also thanked Bjoern Zeeb, Adrian Chadd, Sheng-Yi Hung, and Minsoo Choo, along with fellow interns Sourojeet Adhikari and Nimish Jain, for their guidance, technical help, and willingness to exchange ideas.

The FreeBSD Foundation would also like to thank Jim for his contributions throughout the semester. We appreciate the curiosity, dedication, and persistence he brought to his work, as well as his willingness to take on new challenges and explore different areas of the FreeBSD Project.

Looking back, Jim describes the internship as challenging at times, but ultimately an opportunity to learn in a way that would be difficult to replicate elsewhere.

He appreciated the flexibility of the work, the emphasis on independent exploration, and the freedom to experiment without being afraid of getting everything right immediately.

“I feel that the time I got to pursue the bits I’m interested in, to try things out without fear of repercussions, and to pore over technical goodies was a valuable experience for my first internship,” he said.

For someone who started programming by experimenting with a graphing calculator, that curiosity remains at the center of Jim’s work.

Only now, the system he’s exploring is a little bigger.

The post FreeBSD Foundation Intern Jim Huang Chen on Raspberry Pi Support and Open Source first appeared on FreeBSD Foundation.

Top

Service Discovery mit Zookeeper

Post by Kristian Köhntopp via Die wunderbare Welt von Isotopp »

Ein anpaßbares Pattern für Service Discovery, hier am Beispiel MySQL – aber es kann im Grunde für jede andere Flotte von Servern verwendet werden. Ein Dienst veröffentlicht seine Bereitschaft in Zookeeper. Ein lokaler Agent beobachtet diesen Zustand und materialisiert daraus eine Datei. Anwendungen lesen die Datei und müssen Zookeeper weder kennen noch erreichen können; sie arbeiten mit der Datei und müssen diese bei Änderungen neu lesen.

Das Pattern stammt aus dem Betrieb großer MySQL-Installationen bei Booking.com. Es funktioniert genauso für andere Datenbanken, Caches, Message-Broker oder beliebige Pools gleichartiger Dienste.

Der wichtige Punkt ist die Trennung der Aufgaben:

  • Zookeeper ist die konsistente Control Plane für die Mitgliedschaft im Pool.
  • Eine lokale Datei ist die möglicherweise kurz veraltete, aber hoch verfügbare Sicht der Data Plane.
  • Der Übergang zwischen beiden ist ein Reconciliation Loop mit Eventual Convergence.

Woher das Problem kam

Booking.com betrieb MySQL in Replikationsbäumen über drei Rechenzentren. An der Wurzel stand ein Primary. In jedem Rechenzentrum übernahm ein Intermediate Primary die Verteilung der Writes an lokale Leaf Replicas.

flowchart TD
P["Primary in RZ A"]
IA["Intermediate Primary in RZ A"]
IB["Intermediate Primary in RZ B"]
IC["Intermediate Primary in RZ C"]
A1["viele Produktions-Replikas in RZ A"]
B1["viele Produktions-Replikas in RZ B"]
C1["viele Produktions-Replikas in RZ C"]
P --> IA
P -->|"ein Write-Stream über die Langstrecke"| IB
P -->|"ein Write-Stream über die Langstrecke"| IC
IA --> A1
IB --> B1
IC --> C1

Auf diese Weise gingen die Writes nur einmal pro entferntem Rechenzentrum über eine Long-Distance-Verbindung. Der dortige Intermediate Primary verteilte sie lokal weiter. Die Zahl der Leaf Replicas vergrößerte daher nicht die Zahl der WAN-Verbindungen.

Anwendungen schrieben auf den Primary und lasen von lokalen Leaf Replicas. Nicht jede Replica war dafür jederzeit geeignet. Eine Produktions-Replika mußte unter anderem erreichbar sein, laufende Replikation und akzeptablen Replikationsverzug haben und durfte sich nicht in Wartung befinden.

Die Menge geeigneter Server war dynamisch. Neue Maschinen kamen hinzu, alte wurden entfernt, Replikas fielen zurück oder wurden aus einem Pool genommen. Die Clients brauchten also nicht die Liste aller MySQL-Server, sondern die Liste der jetzt für ihren Zweck geeigneten lokalen Endpoints.

Eine ausführlichere Beschreibung der MySQL-Topologie steht in That’s a lot of databases .

Drei Generationen Discovery

Die Discovery durchlief drei Generationen: einen Layer-2-Load-Balancer, DNS und schließlich Zookeeper. Diese Alternativen waren bereits Teil einer System-Design-Frage zu MySQL bei Booking.com . Hier geht es um die dort nur angerissene Zookeeper-Variante.

Layer 2 paßte nicht mehr zum Netz

Der erste Load-Balancer arbeitete auf Layer 2. Das war brauchbar, solange das Netz die dafür benötigten gemeinsamen Broadcast-Domains bereitstellte.

Mit dem Wechsel auf ein geroutetes Leaf-and-Spine-Fabric war diese Annahme nicht mehr gegeben. Virtuelle Adressen mit ARP, VRRP oder ähnlichen Verfahren lassen sich nicht einfach über die Grenzen der L2-Domains verschieben. Man kann um die neue Netzstruktur herum wieder L2-Inseln und zusätzliche Komponenten bauen, aber dann arbeitet die Service Discovery gegen die Netzarchitektur statt mit ihr.

DNS konvergierte schlecht kontrollierbar

DNS beseitigte die Abhängigkeit von einer gemeinsamen L2-Domain, brachte aber eine andere Klasse von Problemen:

  • Autoritative Updates und die Sicht der Clients sind zwei verschiedene Vorgänge.
  • Resolver und Anwendungen cachen mit unterschiedlichen Regeln.
  • Manche Clients lösen einen Namen nur beim Start oder beim Aufbau eines Connection Pools auf.
  • Positive und negative Caches reagieren unterschiedlich auf Änderungen.
  • Das schnelle und verläßliche Entfernen eines ungeeigneten Servers ist schwer.

Auch DNS konvergiert schließlich. Zeitpunkt und Zwischenzustände lassen sich bei schnell veränderlichen Server-Pools jedoch schlecht kontrollieren.

Daher ist man zu einem Zeitpunkt auf Zookeeper umgestiegen, um Server zu registrieren und um Clients zu informieren, wo welche Server erreichbar sind.

Zookeeper-Grundlagen

Zookeeper speichert Daten in einem hierarchischen Baum. Ein Knoten in diesem Baum heißt Znode. Anders als bei einem Unix-Dateisystem kann ein Znode gleichzeitig Daten enthalten und Kinder haben. Der Pfad /services/search kann also Konfiguration enthalten und zugleich Elternknoten für einzelne Search-Server sein.

Znodes können persistent oder ephemeral sein:

  • Ein persistenter Znode bleibt bestehen, bis ihn jemand explizit löscht.
  • Ein ephemerer Znode gehört einer Zookeeper-Session. Er verschwindet, wenn diese Session endet oder abläuft.

Eine Session ist nicht dasselbe wie eine einzelne TCP-Verbindung. Ein Client kann die Verbindung zu einem Mitglied des Zookeeper-Ensembles verlieren und sich mit einem anderen verbinden, ohne seine Session zu verlieren. Während einer kurzen Unterbrechung bleiben seine ephemeren Znodes daher bestehen.

Erst wenn der Client nicht innerhalb des ausgehandelten Session-Timeouts zurückkehrt, läuft die Session ab. Zookeeper entfernt dann deren ephemere Znodes. Kommt der Client später zurück, beginnt er eine neue Session und muß seine ephemeren Znodes neu anlegen.

Ein Client kann außerdem Watches auf Znodes setzen. Ein Watch ist eine einmalige Benachrichtigung darüber, daß sich der beobachtete Zustand geändert haben könnte. Danach muß der Client den Watch erneut installieren. Die Benachrichtigung ist kein vollständiger Diff und keine dauerhaft gespeicherte Event-History, sondern nur eine Mitteiling, daß sich die Dinge geändert haben und die Znodes unter dem Watch neu gelesen werden müssen. Mehrere Änderungen können zu einer einzigen relevanten Benachrichtigung zusammenfallen (“Debouncing”).

Diese vier Eigenschaften ergeben zusammen das Discovery-Primitive:

  • Der Znode-Baum organisiert Services und Pools.
  • Persistente Znodes definieren deren Struktur.
  • Ephemere Znodes repräsentieren die an eine Session gebundenen Mitglieder.
  • Watches invalidieren die bei den Consumers gespeicherte Sicht.

Zookeeper machte Membership explizit

In Zookeeper konnte jeder Pool als Pfad und jeder geeignete Server als dessen Kind dargestellt werden. Änderungen wurden damit explizite Zustandsänderungen statt indirekte Folgen von DNS-Caches.

flowchart TD
P["/production-readers-rz-a<br/>persistent"]
A["db-rza-017<br/>ephemeral<br/>10.1.17.12:3306"]
B["db-rza-023<br/>ephemeral<br/>10.1.23.12:3306"]
C["db-rza-041<br/>ephemeral<br/>10.1.41.12:3306"]
P --> A
P --> B
P --> C

Der Pool-Knoten ist persistent. Die Member sind ephemeral und gehören jeweils einer Zookeeper-Session. Endet die Session, entfernt Zookeeper die zugehörigen Member automatisch.

Auf einem MySQL-Server zum Beispiel läuft ein Healthchecker neben dem mysqld, verbindet sich mit diesem und entscheidet, ob dieser Dienst bereit ist. Ist er bereit, erzeugt der Healthchecker den ephemeren Knoten. Ist er nicht mehr geeignet, entfernt er ihn oder beendet seine Session.

Ein ephemerer Knoten ist dabei ein Healthcheck-Resultat, aber keine Garantie. Er bedeutet:

Der Besitzer dieser Zookeeper-Session lebt und hält den Endpoint weiterhin für geeignet.

Ein abgestürzter Server bleibt daher bis zum Ablauf der Session sichtbar. Ein hängender Healthchecker kann einen ungeeigneten Server weiterhin veröffentlichen. Der Client muß Verbindungsfehler trotz Service Discovery behandeln können.

Watches sind keine Events

Zookeeper-Watches sind keine zuverlässige Ereignisaufzeichnung. Ein Watch bedeutet nicht: „Verarbeite genau diese Änderung.“ Er bedeutet:

Der beobachtete Zustand könnte sich geändert haben. Lies ihn neu.

Das ist für Discovery ideal. Der Client interessiert sich nicht für jede Zwischenstufe einer Änderung:

db17 hinzugefügt
db23 entfernt
db17 geändert
db41 hinzugefügt

Er braucht nur den Zustand, gegen den er schließlich konvergieren soll:

Der Pool besteht jetzt aus db17 und db41.

Der Consumer installiert seine Watches erneut und liest den vollständigen Pool. Wird währenddessen wieder eine Änderung signalisiert, beginnt er den Vorgang noch einmal. Nach einem Verbindungsabbruch macht er ebenfalls einen vollständigen Rescan.

Verpaßte Zwischenzustände sind bedeutungslos. Es muß nur irgendwann wieder eine vollständige Reconciliation stattfinden. Das System garantiert Eventual Convergence, nicht die Beobachtung jedes Updates.

flowchart TD
S["Service und Healthchecker"] -->|"ephemerer Member"| Z["Zookeeper Pool"]
Z -->|"Watch: Zustand könnte geändert sein"| A["lokaler Agent"]
A -->|"vollständigen Pool lesen"| Z
A -->|"temporäre Datei + rename(2)"| F["lokale Endpoint-Datei"]
F -->|"bei Verbindungsaufbau lesen"| C["Anwendung"]
C -->|"direkte Verbindung"| S

Änderungen dürfen zusammenfallen

Bei einer größeren Wartungsaktion können viele Pool-Änderungen kurz hintereinander auftreten. Es ist nicht sinnvoll, jeden Zwischenzustand auf alle Clients zu verteilen.

Der Agent wartet nach einer Invalidierung eine zufällige Zeit bis zu einem konfigurierten Maximum. Weitere Änderungen in dieser Zeit werden zusammengefaßt. Nach dem Ende des Änderungsbursts erzeugt der Agent eine neue vollständige Sicht.

Das hat zwei erwünschte Effekte:

  • Viele Änderungen erzeugen nur wenige neue Dateien.
  • Nicht alle Agents lesen gleichzeitig denselben Pool aus Zookeeper.

Der zufällige Delay begrenzt nicht die Zeit seit der ersten Änderung. Bei andauernden Änderungen kann die Materialisierung weiter aufgeschoben werden. Das ist hier akzeptabel: Eine konsistente Sicht nach Ende des Bursts ist wichtiger als die Wiedergabe aller Zwischenzustände.

Die Datei ist die lokale materialisierte Sicht

Der Agent schreibt für den Pool eine einfache Datei:

10.1.17.12:3306 # db-rza-017
10.1.23.12:3306 # db-rza-023
10.1.41.12:3306 # db-rza-041

Das Format ist nicht wesentlich. Es kann Text, JSON oder ein Format für eine bestimmte Clientbibliothek sein. Wesentlich ist, daß die Datei eine vollständige materialisierte Sicht darstellt.

Die Anwendung muß dadurch keine Zookeeper-Bibliothek enthalten. Sie braucht keine Sessions zu verwalten, keine Watches neu zu installieren und keine Reconnects zu implementieren. Beim Aufbau einer Verbindung liest sie die lokale Datei, wählt einen passenden (zufälligen!) Endpoint und verbindet sich direkt.

Die Datei ist gleichzeitig ein Read Cache. Ein Verbindungsaufbau erzeugt keinen Read im Zookeeper-Cluster. Der Agent liest nur beim Start, nach einer Invalidierung und nach einem Reconnect. Ein Agent pro Host kann dieselbe Sicht für viele lokale Prozesse bereitstellen.

Die Datei wird atomar ersetzt

Eine Serverliste darf beim Lesen nicht halb alt und halb neu sein. Der Agent schreibt den neuen Inhalt deshalb nicht direkt in die Zieldatei:

endpoints.$pid schreiben
endpoints.$pid schließen
rename("endpoints.$pid", "endpoints")

Die temporäre Datei liegt im selben Verzeichnis und damit auf demselben Filesystem wie das Ziel. rename(2) ersetzt dann den Verzeichniseintrag in einer atomaren Operation. Ein Reader sieht entweder die alte oder die neue vollständige Datei, niemals eine teilweise geschriebene Version.

Das Verfahren wird ausführlicher in But is it atomic? diskutiert.

Reader müssen die Datei für eine neue Sicht erneut öffnen. Ein tail -f kann am alten Inode hängenbleiben, nachdem der Name bereits auf die neue Datei zeigt. Darum verwenden wir für solche Dateien immer tail -F: Es folgt dem Dateinamen, erkennt den Austausch und öffnet die neue Datei.

Für diese Anwendung ist atomare Sichtbarkeit wichtig, nicht garantierte Persistenz nach einem Stromausfall. Die Datei ist ein rekonstruierbarer Cache, kein autoritativer Datenspeicher. Zusätzliche fsync()-Operationen lösen hier kein relevantes Discovery-Problem.

Loss of Control ist nicht Loss of Service

Zookeeper ist ein Konsenssystem. Wenn es kein Quorum herstellen kann, darf es vorübergehend lieber keine Antwort geben als eine möglicherweise falsche. Das ist für die Control Plane die richtige Entscheidung, darf aber nicht jeden Verbindungsaufbau in der Data Plane blockieren.

Der Agent behält bei einem Zookeeper-Ausfall die zuletzt vollständig geschriebene Datei. Bestehende und neue Prozesse können weiter Endpoints auswählen. Nach der Rückkehr von Zookeeper liest der Agent den gesamten Pool neu und konvergiert gegen den aktuellen Zustand.

Die Materialisierung erhält also die Verfügbarkeit der Data Plane auf Kosten der Aktualität:

Eigenschaft Zookeeper Lokale Datei
Zustand aktuell und koordiniert möglicherweise veraltet
Verfügbarkeit bei fehlendem Quorum eingeschränkt lokal weiter lesbar
Zugriff Netzwerk und Clientbibliothek lokaler Dateizugriff
Änderung Watch als Invalidierung atomarer Austausch
Last Read bei Reconciliation beliebig viele lokale Reads
Aufgabe Control Plane materialisierte Data-Plane-Konfiguration

Die Datei garantiert während eines Ausfalls nicht, daß jeder gelistete Server noch erreichbar ist. Sie garantiert eine vollständige letzte Auswahl. Der Client probiert beim Verbindungsfehler einen anderen Endpoint. Aus einem Ausfall der Control Plane wird dadurch Staleness statt eines unmittelbaren Ausfalls der Data Plane.

Dieses Verhältnis zwischen Control Plane und Data Plane ist aus zwei anderen Perspektiven in Service Mesh und Konsenssysteme beschrieben.

Was das Pattern garantiert

Das System gibt drei nützliche Garantien:

  • Ein Reader sieht eine vollständige alte oder neue Endpoint-Datei.
  • Der letzte bekannte Zustand bleibt ohne verfügbare Control Plane nutzbar.
  • Nach der Rückkehr der Control Plane konvergiert der Agent gegen den aktuellen Pool.

Es gibt bewußt keine Garantie für Folgendes:

  • Der Consumer sieht jeden Zwischenzustand.
  • Die lokale Datei ist während eines Ausfalls aktuell.
  • Ein gelisteter Endpoint ist beim nächsten Connect tatsächlich erreichbar.
  • Alle Consumers wechseln gleichzeitig auf denselben neuen Zustand.

Diese Einschränkungen sind keine Fehler im Design. Sie sind die Folge einer bewußten Entscheidung: Service Discovery muß für diesen Anwendungsfall schnell und betriebssicher konvergieren, aber sie muß kein synchrones Protokoll im Request-Pfad sein.

Das allgemeine Pattern

MySQL war der konkrete Anwendungsfall, ist aber keine Voraussetzung. Das Pattern paßt, wenn folgende Bedingungen gelten:

  • Es gibt dynamische Pools gleichartiger Endpoints.
  • Ein lokaler Agent kann den zentralen Zustand beobachten.
  • Consumers können mit einer vollständigen, kurzzeitig veralteten Sicht leben.
  • Consumers behandeln Fehler einzelner Endpoints ohnehin selbst.
  • Der zentrale Discovery-Dienst soll nicht im Request- oder Connect-Pfad liegen.

Eine ausführbare Python-Demonstration steht im Repository zkdemo . Sie registriert ephemere Server, beobachtet Pool-Änderungen, faßt Änderungsbursts zusammen und ersetzt die lokale Endpoint-Datei atomar.

Ich behaupte nicht, daß eine Datei moderner als DNS oder ein Load-Balancer wäre. Aber wir sehen hier eine saubere Trennung: Zookeeper entscheidet konsistent über Membership. Der Agent materialisiert diese Entscheidung lokal. Die Anwendung arbeitet mit dem letzten vollständigen Ergebnis weiter, auch wenn die Control Plane gerade nicht erreichbar ist.

Top

Valuable News – 2026/08/17

Post by Vermaden via 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗 »

The Valuable News weekly series is dedicated to provide summary about news, articles and other interesting stuff mostly but not always related to the UNIX/BSD/Linux systems. Whenever I stumble upon something worth mentioning on the Internet I just put it here.

Today the amount information that we get using various information streams is at massive overload. Thus one needs to focus only on what is important without the need to grep(1) the Internet everyday. Hence the idea of providing such information ‘bulk’ as I already do that grep(1).

The Usual Suspects section at the end is permanent and have links to other sites with interesting UNIX/BSD/Linux news.

Past releases are available at the dedicated NEWS page.

UNIX

[CFT] FreeIPA Server on FreeBSD.
https://github.com/joneum/FreeBSD-freeipa-server

Sharing Dual Licensed Drivers between Linux and FreeBSD.
https://freebsdfoundation.org/blog/sharing-dual-licensed-drivers-between-linux-and-freebsd/

FreeBSD Git Weekly: 2026-08-03 to 2026-08-09.
https://freebsd-git-weekly.tarsnap.net/2026-08-03.html

OpenSSH 10.5 Released.
https://undeadly.org/cgi?action=article;sid=20260811113606

FreeBSoD: Leveraging Language Models to Find and Exploit Kernel Bugs (Part 1 of 2).
https://praetorian.com/blog/ai-vulnerability-research-freebsd-kernel/

FreeBSoD: Leveraging Language Models to Find and Exploit Kernel Bugs (Part 2 of 2).
https://praetorian.com/blog/llm-kernel-exploit-development/

First Successful FreeIPA Server Installation on FreeBSD.
https://linkedin.com/posts/jochen-neumeister-361096147_freebsd-freeipa-share-7492972762148515840-0rvx/

FreeBSD Laptop Compatibility.
https://freebsdfoundation.github.io/freebsd-laptop-testing/

DTrace Memory Analyzer for FreeBSD.
https://github.com/oshogbo/dtrace-memanalyzer

LibreFS (Minio Fork) Builds and Runs Well on FreeBSD.
https://x.com/vermaden/status/2087284456889397311

New video(4) Driver Landed in CURRENT.
https://lists.freebsd.org/archives/freebsd-current/2026-August/010629.html

Skip2 Networks – What is FreeBSD?
https://www.skip2.net/blog/what-is-freebsd

Move FreeBSD System Between ZFS Disks.
https://vermaden.wordpress.com/2026/08/14/move-freebsd-between-zfs-disks/

Custom FreeBSD UCARP Setup.
https://vermaden.wordpress.com/2026/08/15/custom-freebsd-ucarp-setup/

Running Wiki.js in FreeBSD 15.1 Jail.
https://dkade.com/posts/wikijs_freebsd_jail/

FreeBSD 14.5-BETA2 Now Available.
https://lists.freebsd.org/archives/freebsd-stable/2026-August/004277.html

Minimal Intel ME Diagnostic Driver for FreeBSD in Review.
https://reviews.freebsd.org/D58863

Incoming www/linux-brave DRM ready Port Comming to FreeBSD.
https://linkedin.com/posts/dteske_i-have-recently-put-a-fair-amount-of-work-ugcPost-7494197143814017024-5VZ1/

There is No Linux Admin.
https://vivianvoss.net/blog/no-linux-admin

What 'sh -x' Mostly Does Not Tell You About Shell Script.
https://utcc.utoronto.ca/~cks/space/blog/programming/ShXWhatYouMiss

SeaweedFS on FreeBSD and Rather Deep Rabbit Hole.
https://tara.sh/posts/2026/2026-08-13_seaweedfs_freebsd_rabbithole/

Reproduce Missing etcmerge(8) from FreeBSD 15.0 to 15.1 Upgrade.
https://dan.langille.org/2026/08/12/attempting-to-reproduce-the-missing-etcmerge-from-15-0-to-15-1-upgrade/

FreeBSD 14.3 on Parallels 26.
https://conradresearch.com/design-distilled/freebsd-14-on-parallels-26

Cloudflare Tunnels on FreeBSD 14.3.
https://conradresearch.com/design-distilled/cloudflare-tunnels-on-freebsd

Installing FreeBSD on OVHcloud Bare Metal Server.
https://conradresearch.com/design-distilled/installing-freebsd-on-OVHcloud-bare-metal-server

Installing Infisical on FreeBSD.
https://conradresearch.com/design-distilled/installing-infisical-on-freebsd

Building Turso Golang Client on FreeBSD.
https://conradresearch.com/design-distilled/building-turso-golang-client-on-freebsd

Temporal Dev Server on FreeBSD.
https://conradresearch.com/design-distilled/temporal-dev-server-on-freebsd

Immutable Software Deploys Using ZFS Jails on FreeBSD.
https://conradresearch.com/design-distilled/immutable-software-deploy-zfs-jails

Tailscale Exit Node on FreeBSD.
https://conradresearch.com/design-distilled/tailscale-exit-node-on-freebsd

Tailscale SSH Server Access on FreeBSD.
https://conradresearch.com/design-distilled/tailscale-ssh-server-access-on-freebsd

The fw_update(8) Utility Explained and How It Works.
https://bsd-audit.com/openbsd/fw_update-explained/

Replacing security/pam-ssh-agent-auth with security/pam-ssh-agent Package.
https://dan.langille.org/2026/08/17/replacing-security-pam-ssh-agent-auth-with-security-pam-ssh-agent/

FreeBSD Home Server – Part 1 – OS Install.
https://subnetspider.com/2026/08/16/freebsd-home-server-part1.html

FreeBSD Wochenruckblick 2026/07/6-12. [German]
https://tgeppert.de/2026/07/13/freebsd-wochenrueckblick-6-12-juli-2026/

FreeBSD Wochenruckblick 2026/07/14–20. [German]
https://tgeppert.de/2026/07/20/freebsd-wochenrueckblick-14-20-juli-2026/

UNIX/Audio/Video

NetBSD 11 Released with Continued i386 and Improved RISC-V Support.
https://youtube.com/watch?v=H_rOjsGDM7g

Install FreeBSD as Home Lab Server.
https://youtube.com/watch?v=EEkfeibYirE

Configure FreeBSD as Home Lab Server.
https://youtube.com/watch?v=2jgiIR9IAZQ

Configure and Use VNET Jails in FreeBSD.
https://youtube.com/watch?v=IdMloTbM9lE

Your Home Lab FreeBSD Bhyve Virtualization Host.
https://youtube.com/watch?v=PQ-mo–2pxg

Create Jail in Sylve – FreeBSD Virtualization and Container GUI – 2026 Version.
https://youtube.com/watch?v=LiFn3hF4UPs

BVCP Bhyve GUI Control Panel for FreeBSD.
https://youtube.com/watch?v=fo3HNFNS4-Y

BSD Now 676: 10 PRINT GOTO 10.
https://www.bsdnow.tv/676

Hardware

Keep Android Open – Stop Google from Limiting APK File Usage.
https://change.org/p/keep-android-open-stop-google-from-limiting-apk-file-usage

Trezor Crypto Wallet Confirms 13,000 Customers Details Exposed in Breach.
https://theregister.com/security/2026/08/14/trezor-confirms-13000-customers-details-exposed/5287734

Supersonic Trebuchet.
https://youtube.com/watch?v=Co57SfcT-h0

Were Mac Touch Bar Problems Software Rather Than Hardware?
https://unsung.aresluna.org/deeper-dive-were-touch-bars-problems-software-rather-than-hardware/

Selection of Older But Still Relevant Tests (Part 5).
https://hwcooling.net/en/selection-of-older-but-still-relevant-tests-part-5/

Life

Other

Gotosocial Reverse Proxy with Wireguard.
https://owleyes.blue/posts/gotosocial-reverse-proxy-with-wireguard/

Desktop Calendar – Thunderbird Design Journey.
https://blog.thunderbird.net/2026/08/desktop-calendar-a-design-journey/

Usual Suspects

BSD Weekly.
https://bsdweekly.com/

DiscoverBSD.
https://discoverbsd.com/

BSDSec.
https://bsdsec.net/

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

BSDTV.
https://bsky.app/profile/bsdtv.bsky.social

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

BSDJedi.
https://youtube.com/@BSDJedi/videos

RoboNuggie.
https://youtube.com/@RoboNuggie/videos

GaryHTech.
https://youtube.com/@GaryHTech/videos

Sheridan Computers.
https://youtube.com/@sheridans/videos

82MHz.
https://82mhz.net/

EOF
Top

Replacing security/pam-ssh-agent-auth with security/pam_ssh_agent

Post by Dan Langille via Dan Langille's Other Diary »

Yesterday, I learned that security/pam-ssh-agent-auth is abandoned and deprecated.

Looking back, I first used this about 13 years ago, and wrote about it while describing how I set up ansible clients.

Today, I tried one of the two recommended replacement:

  1. security/pam_rsshmentioned by Romain Tartière
  2. security/pam_ssh_agent – the one I’m trying

Note the package vs the port

Note this point. The package name is:

[15:03 empty dvl ~] % pkg info -x pam-ssh-agent
pam-ssh-agent-0.9.7

The origin / port name is:

[15:03 empty dvl ~] % pkg info -o pam-ssh-agent
pam-ssh-agent-0.9.7            security/pam_ssh_agent

Note dashes vs underscores. I original had the origin wrong in this title.

Very much a drop-in replacement

Here’s what I did.

Install it:

The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	pam-ssh-agent: 0.9.7 [local]

Number of packages to be installed: 1

The process will require 1 MiB more space.
413 KiB to be downloaded.

Proceed with this action? [y/N]: y
[empty.int.unixathome.org] [1/1] Fetching pam-ssh-agent-0.9.7: 100%   413 KiB 422.5 kB/s    00:01    
Checking integrity... done (0 conflicting)
[empty.int.unixathome.org] [1/1] Installing pam-ssh-agent-0.9.7...
[empty.int.unixathome.org] [1/1] Extracting pam-ssh-agent-0.9.7: 100%

What did it install?

[11:32 empty dvl ~] % pkg info -l pam-ssh-agent
pam-ssh-agent-0.9.7:
	/usr/local/lib/pam_ssh_agent.so

Adjust /usr/local/etc/pam.d/sudo:

#auth sufficient /usr/local/lib/pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
auth sufficient /usr/local/lib/pam_ssh_agent.so      file=~/.ssh/authorized_keys
auth required pam_deny.so
account include system
session required pam_permit.so

The commented out line is the old. The new line is the second line.

That’s it. Nothing to restart…

However, there is more to this configuration than shown. That did not need to be modified for this. See the “Configure ssh agent auth for sudo” section of this post.

I did delete the deprecated package: sudo pkg delete pam_ssh_agent_auth

Top

DFG Heisenberg project post-mortem

Post by Andreas K. Hüttel via the dilfridge blog »

This post is an excerpt from the formally non-public part of my DFG Heisenberg grant final report (about half of the actually interesting part). I hope it will help people do better. The remaining part of the report can be found in a subsequent blog post. Some personal information has been redacted.

The backstory

In 2018, when I first submitted a Heisenberg program proposal, funding was declined. One referee report was full of misinformation and misinterpretations, the other criticized the methods in one of the suggested research subtopics. Overall this sufficiently lowered the ranking of the entire submission. Anyway, as the saying goes, stand up again, brush down coat, re-adjust crown, keep going. The proposal was updated, the doubtful part replaced, a response to the misinformation added, and of course also some more exciting research ideas included.

At that point I decided to go for full risk. While the DFG Emmy Noether program deliberately funds a junior research group consisting of a PI and PhD students or a post-doc, the DFG Heisenberg program is more adjusted along the customs of humanities and funds the PI alone. It is still supposed to provide a base for independent research at the level of associate professor though, which is why one can concurrently submit a supporting research grant proposal for equipment and personnel. The advantage of doing so is that this can form a coherent overall funding package, the disadvantage is that a negative review of any part of the package will drag it down in its entirety, see above.

Complementing the overarching Heisenberg proposal for my own position and its research, I submitted in 2019 two additional research proposals ("Einzelanträge"). One focused on the continuation of the Emmy Noether project, tuning optomechanics of single-wall carbon nanotubes towards strong coupling and coherent control, and including such nice ideas as, e.g., coupling mechanics with coherent states in double quantum dots. This was a highly complex project, intended for two PhD students (and the two students were really required because of the combination of multi-step fabrication and complicated experiment). In addition, it was adjusted to fit to the topic of a Graduate Research School (GRK) proposal under preparation back then in Regensburg. The idea of the second grant was to try out something new, and establish quantum transport measurements on MoS2 nanotubes – a material where already a lot of optical measurements existed but the transport physics of quantum dots was so far completely unexplored. Here, one PhD student was requested; furthermore the topic was deliberately chosen to be in the area of interest of a new Regensburg Collaborative Research Centre (SFB), SFB 1277, in the hope of further financial support options.

Because of the significant amount of university-bound equipment acquired from SFB funds, and the potential difficulties of moving “my” large dilution refrigerator, I chose again Universität Regensburg as host institution.

In the meantime, my employment contract in Regensburg ran out (thanks Wissenschaftszeitvertragsgesetz), so I went to the Low Temperature Laboratory, Department of Applied Physics, Aalto University, Finland for one year as full-time employed visiting professor; my thanks go to Prof. Pertti Hakonen for making this possible. Two weeks later COVID broke out, but Aalto was a great place to be both scientifically and to sit out the pandemic. And in autumn a sequence of excellent news followed; the Heisenberg grant was approved, and in addition the Emmy Noether work on microwave optomechanics was awarded the Walter Schottky Prize 2021 of the German Physical Society. So, things were clearly brightening up, or so I thought.

A more detailed inspection of the grant approval letter provided a somewhat more mixed image. One referee explicitly and clearly supported the request for two PhD students in the optomechanics project, the other also explicitly lauded all details, including the excellent funding plan, of the optomechanics project, but additionally stated that the impact of the MoS2 nanotube project would be larger (this was likely written before the announcement of the Walter Schottky Prize). As result, only one PhD position for optomechanics was granted by the funding committee. Hope always dies last, but in retrospect I can now confirm my immediate suspicion that this reduction of funding killed the optomechanics project from the start. My initial “plan B” for additional optomechanics funds was not available anymore, since the Regensburg Graduate Research School had in the meantime made an ultrafast turn towards other research topics. Further, even though this project was the direct continuation of the Walter Schottky Prize work, it turned out to be extremely difficult to find and hire a PhD student for it. The project started on 16 March 2021, and only on 1 August 2022 a PhD student arrived.

In comparison, the MoS2 nanotube project start-up went much more smooth, and [...] started work on his PhD straight on the 16 March 2021. All hope of a financially significant participation in the Regensburg SFB 1277 was however shattered already by a brief conversation with the back then SFB speaker, who made clear that nothing beyond appointing me “associated member” would even be considered. Well, you can't allow “junior scientists” to become too successful…

Scientific progress

I had attempted to keep the optomechanics project going in Regensburg during my time in Finland via a remotely-supervised MSc student, who successfully optimized coplanar waveguide resonator geometries and produced and tested the corresponding devices. When I came back, I quickly found another MSc student who was very enthusiastic to start with optomechanics experiments. However, we also quickly found out that the nanotube growth oven had broken in the meantime, requiring the whole process to be optimized from the start, and the MSc project literally became a year of getting carbon nanotube growth going again from zero. Now in 2026 (!) the quality of nanotubes transferred into a circuit is finally showing excellent results again. That said, the nanotube optomechanics project had many delicate parts, from nanotube growth and transfer to coplanar resonator chip design and fabrication, and no number of MSc students recruited into my group could really replace the missing second PhD student.

[...] On the MoS2 nanotube side, progress was slow but steady, and the PhD student did excellent work. Making contacts to MoS2 nanotubes turned out to be even more complex than contacts to carbon nanotubes or a 2D MoS2 monolayer. A technical breakthrough in the latter system by researchers from MIT and TSMC, among others, provided a path forward, and indeed their approach also led to occasional good results with the MoS2 nanotubes. Obtaining these good results reproducibly, however, was again another complex optimization step; we solved that in 2025 and subsequently managed first physically interesting low-temperature measurements.

In general, across both subprojects, work was slowed down very much by continuous equipment break-downs and oddities in the Regensburg cleanroom. "The SEM for e-beam writing is down" turned out to be one highly regular e-mail subject (for any possible value of "the SEM"). Mystery changes in resist properties, micrometer-scale shifts in the written structures, interruptions in the air conditioning that led to water condensation in the whole cleanroom, ... The department bought a Heidelberg Instruments mask-less aligner (a laser writer for lithography), which was nice but of limited usefulness – since for nanophysics you actually need nano-resolution! Plus there were some other annoying events; e.g., during the installation of a new dilution refrigerator next door someone opened up our (then evacuated) 3He/4He circuit in the pump room to air, which we only noticed when we tried to cool down and suddenly were pumping air into the cold dilution refrigerator insert. Luckily, nearly no isotope mixture was lost.

Experimental work took significantly longer than expected, but eventually did yield interesting results right at the end. As stated above, for the research details of the two subprojects, I refer to the final reports of the research grants [...] and [...].

[...]

Early career stage researchers

I am proud to be able to say that during my ~16 years in Regensburg I have supervised 7 PhD students and 27 MSc or Diplom students. During the Heisenberg period specifically, two PhD students should be named, [...] and [...]. [...] is currently helping a new professor in Regensburg build up his lab on a post-doc position and considering remaining in academia (which he would definitely be suited for). [...] is still busy measuring beautiful data and writing up his dissertation, while being paid by SFB1277.

At the end of the official project runtime (and my employment) in March three MSc students were still active; two have graduated by now, the third one recently handed in his thesis.

Top

DFG Heisenberg post-mortem, part 2

Post by Andreas K. Hüttel via the dilfridge blog »

This post contains remaining parts of my DFG Heisenberg grant final report, by now long submitted and accepted by the DFG. I hope it will be of use, in particular to future DFG grant candidates. The text also somewhat explains why I'm fed up with academia, Regensburg, and physics right now (in no particular order and to varying degrees). The first part of the report can be found in a previous post. Some personal information has been redacted.

Qualification, career, …

During the Heisenberg period 2021-2026, submitted applications for professorships resulted in 8 invitations for presentation and discussion: [...]

A recurrent topic over all my years in academia was that appointment procedures for professorships either failed or that positions were handed to local Emmy Noether, Heisenberg, Juniorprofessor, etc. candidates – much more than expected from past times when the spectre of unwanted “Hausberufung” (in-house appointment) was looming over such events. From that point of view it was equally disappointing that, once I applied for a position in Regensburg, I was immediately told by a member of the appointment commission that my application would be sorted out for exactly that reason. When I spoke to an external member of the appointment commission for that professorship, that external member did not even know that I had applied for the position. In parallel, somewhat doubtful direct appointments to professorships took place in the department.

Further frustration originated from the fact that the Regensburg physics department decided to rewrite their internal regulations such that even after 6 years of Privatdozentur (senior lecturer with habilitation) they only award the title of Außerordentlicher Professor (associated professor, a title without salary) to candidates with a permanent university position. My corresponding petition never received any written response, only oral comment that this is not done anymore. The motivation behind all this is unclear, but it certainly does not make Regensburg more attractive to (somewhat) junior scientists.

A four-eyes career conversation with Mr. Dean of the Faculty resulted in charming comments such as “the best we can do is half an E13 position in the experimental collection maintenance of the undergraduate lectures in a year or so, maybe you could do some research on the side there” and “as a Heisenberg you are an academic legacy problem” (the original German term was “akademische Altlast”). Plus remarks like “we are not going to hand out any (even unpaid) teaching assignments (“Lehraufträge”) to an external Privatdozent anymore, so you’ll lose that title anyway soon for lack of teaching.”

The final cherry on top was then getting berated by another influential senior faculty member about producing insufficient results and being unable to supervise – which is pretty thick coming from someone who barely finds any MSc students, having a reputation among students for erratic grading there. To quote a colleague from Regensburg with permanent employment who should probably stay anonymous, “Der professorale Dünkel ist stark in der Fakultät” (roughly translated, the professorial sense of self-importance is tantamount in the department).

With all these experiences as background, I strongly recommend to anyone with a grant such as DFG Emmy Noether or Heisenberg not to join the Regensburg physics department, but go somewhere else. You and your work will be valued more, and that by far compensates for any Regensburg “excellence”. [...]

Teaching and scientific events

With already significant teaching experience, I decided to mostly focus on research and supervision during the Heisenberg period – with the exception of a “Low Temperature Physics” course where the usual lecturer was on sabbatical. Regarding scientific events, I had requested a moderate amount of funding for a workshop on inorganic nanotubes in [...], which would have fitted quite well as add-on to the workshops of SFB 1277. This was however declined – accordingly, it also did not have priority for me anymore either.

Perspective

I enjoyed university research and teaching as well as working with students, establishing a research group, quantum device fabrication, and complex measurements very much. With the “orderly shutdown” of the group comes that still some students need to graduate and that some results will still be written up and submitted for publication (at the time of this report two papers have been submitted and another two or three might follow); however, I have cleared out my office the day of the end of my employment contract. 

Out of a certain stubbornness, I will keep teaching my 2SWS per year Titellehre for now – as confirmed by the faculty administration, a teaching appointment (“Lehrauftrag”) is legally not required for that, and as a consequence the students will be treated to a block course “How to write a thesis, present a talk, …” in October. However, after over 15 years in Regensburg I have learned that being nice, friendly, cooperative, and helpful might get you friendly smiles and occasional money there but not any sustainable support, and that the Regensburg physics system prefers “junior scientists” to be subordinates, not colleagues. Of course someone who does not have the visible backing of his current university immediately also has a weaker position when applying elsewhere. 

There’s a lot more I could write, but that would go beyond scope and purpose of this report. Anyway, it is now time to make a bonfire out of lecture notes, to go out into the wide world, and to do something entirely new. Which, barring big surprises, most likely will not involve physics or a university anymore. 

Thanks to Duong Thi Hai Yen on vecteezy.com for the tomato.

Top

Move FreeBSD System Between ZFS Disks

Post by Vermaden via 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗 »

I made a funny mistake in one of my clients when installing FreeBSD 15.1-RELEASE on their server … I have chosen wrong disk for the installation. The server had 4 local disks – 2 of them were some really low end SATA SSD drives (ada0 and ada1) and the server also had 2 fast NVMe disks (nda0 and nda1). I used Auto (ZFS) option in the bsdinstall(8) installer and chosen (wrongly) the ada1 disk.

This is how my ZFS pool looked like after installation.

freebsd # zpool status zroot
  pool: zroot
 state: ONLINE
config:

	NAME        STATE     READ WRITE CKSUM
	zroot       ONLINE       0     0     0
	  ada1p4    ONLINE       0     0     0

… but this is the ZFS world – nothing stops You from adding as many drives to ZFS mirror as You want – so for a start I used FreeBSD gpart(8) tool to copy the partitions from ada1 disk to the NVME nda0 and nda1 drives.

freebsd # gpart backup ada1 | gpart restore nda0

freebsd # gpart backup ada1 | gpart restore nda1

Then as FreeBSD was installed with BIOS+UEFI option I cloned the freebsd-boot partition and the UEFI partition.

freebsd # dd bs=1m if=/dev/ada1p1 of=/dev/nda0p1 status=progress

freebsd # dd bs=1m if=/dev/ada1p1 of=/dev/nda1p1 status=progress

freebsd # dd bs=1m if=/dev/ada1p2 of=/dev/nda0p2 status=progress

freebsd # dd bs=1m if=/dev/ada1p2 of=/dev/nda1p2 status=progress

Next I added these nda0 and nda1 as mirror devices for ada1 disk. For the record – the ada1p3 is a SWAP device – no need to clone it for obvious reasons.

freebsd # zpool attach zroot ada1p4 nda0p4

freebsd # zpool attach zroot ada1p4 nda1p4

This is when ZFS decided to do the resilvering process immediately (which is good).

freebsd # zpool status zroot
  pool: zroot
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
	continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Aug 13 18:47:35 2026
	199G / 199G scanned, 15.5G / 199G issued at 428M/s
	31.0G resilvered, 7.76% done, 00:07:20 to go
config:

	NAME        STATE     READ WRITE CKSUM
	zroot       ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    ada1p4  ONLINE       0     0     0
	    nda0p4  ONLINE       0     0     0  (resilvering)
	    nda1p4  ONLINE       0     0     0  (resilvering)

errors: No known data errors

We can even track the status of that replication.

freebsd # zpool iostat -v zroot 5
              capacity     operations     bandwidth 
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zroot        199G   229G     25    758  3.11M  42.6M
  mirror-0   199G   229G  3.21K  95.9K   402M  5.38G
    ada1p4      -      -     25    693  3.11M  36.5M
    nda0p4      -      -      0  4.15K    281   403M
    nda1p4      -      -      0  4.41K    305   413M
----------  -----  -----  -----  -----  -----  -----
              capacity     operations     bandwidth 
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zroot        199G   229G  2.89K  8.29K   369M   850M
  mirror-0   199G   229G  2.89K  8.29K   369M   850M
    ada1p4      -      -  2.89K    383   369M  37.1M
    nda0p4      -      -      0  4.00K      0   406M
    nda1p4      -      -      0  3.91K      0   406M
----------  -----  -----  -----  -----  -----  -----
              capacity     operations     bandwidth 
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zroot        199G   229G  2.99K  7.30K   378M   827M
  mirror-0   199G   229G  2.99K  7.30K   378M   827M
    ada1p4      -      -  2.99K    185   378M  19.9M
    nda0p4      -      -      0  3.54K  7.20K   404M
    nda1p4      -      -      0  3.58K      0   404M
----------  -----  -----  -----  -----  -----  -----

After resilvering process is finished we can detach the ada1 drive from the ZFS mirror.

freebsd # zpool detach zroot ada1p4

… and after all these quite simple and predictable operations – everything when the system was still running – we have FreeBSD installation migrated from ada1 disk to ZFS mirror on two NVMe nda0 and nda1 disks as shown below.

freebsd # zpool status zroot
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0B in 00:00:08 with 0 errors on Thu Aug 13 23:20:15
2026
config:

	NAME        STATE     READ WRITE CKSUM
	zroot       ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    nda0p4  ONLINE       0     0     0
	    nda1p4  ONLINE       0     0     0

errors: No known data errors

Its kinda short article (for my standards) but it shows what was needed and possible with ZFS and other FreeBSD tools to do the job. One more thing that its needed to be done is that in BIOS/UEFI you need to add boot option specifying the path to the loader.efi file – separate one for each NVMe drive.

UPDATE 1 – BIOS/UEFI Boot Option

Someone asked me how this is exactly done … and it is done differently in each BIOS/UEFI manufacturer – below one is from some Lenovo ThinkServer system server.

First enter into BIOS/UEFI and go to Boot Settings part.

Next select Add UEFI Full Path Boot Option there.

In the next ‘window’ use Select Device Path Option position.

Next select the drive You know You installed FreeBSD on – this is one of the two NVMe drives I moved FreeBSD to.

Next click <efi> dir.

Next click <freebsd> dir.

Next select loader.efi file.

Next add wanted name – I used FreeBSD/nda0 there.

Click Commit Changes and Exit option.

Next click Change Boot Order and set that FreeBSD/nda0 option as first one.

Do the same for another NVMe disk and add another FreeBSD/nda1 option there.

Alternatively You can do that from within FreeBSD system using efibootmgr(8) command – Important efibootmgr(8) Command – details here.

 

EOF

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Top

Custom FreeBSD UCARP Setup

Post by Vermaden via 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗 »

This entry is sponsored by fme AG company – and this article aspires to share about interesting HA setup on node01a and node01b VMs. Below drawing was created by Tim Serong and greatly visualizes the cluster logic in HA systems 🙂

The interesting case here is that the 10.0.0.x/24 is limited in one of the clients – most IP(s) are taken. With normal carp(4) installation we would need 3 IP(s) from that network – two IP(s) for each of the two nodes and an additional HA IP for the service. To overcome that we will use 3 IPs(2) from different 192.168.0.x/24 network and only one IP from the limited 10.0.0.x/24 network. The net/ucarp port that we will use here has only one disadvantage that we can overcome easily – it does not do anything to MAC addresses of the network interfaces – and knowing how the network switches work – they may ‘redirect’ traffic to ‘bad’ interface with ‘bad’ MAC address – so we will also use something like HA MAC concept and move that HA MAC with the HA IP.

List of these Bhyve VMs below.

bhyve # vm list | grep -e NAME -e node01
NAME      DATASTORE  LOADER     CPU  MEMORY  VNC  AUTO     STATE
node01a   default    uefi       2    4G      -    No       Running (64537)
node01b   default    uefi       2    4G      -    No       Running (60781)

Below You will find summary of IPs(s) and MAC(s) addresses.

192.168.0.11      | node01a IP
192.168.0.12      | node01b IP
192.168.0.100     | node01 HA IP UCARP (technical)
10.0.0.100        | node01 HA IP (service)
10.0.0.1          | node01 HA IP Default Gateway (service)
58:9c:fc:ff:01:ff | node01 HA MAC
58:9c:fc:ff:01:aa | node01a MAC
58:9c:fc:ff:01:bb | node01b MAC

The net/ucarp provides the ‘UP’ and ‘DOWN’ scripts – I just copied them to new /usr/local/etc/ucarp/ dir and added some content to them.

node0a # pkg info -l ucarp 
ucarp-1.5.2.20171201:
        /usr/local/etc/rc.d/ucarp
        /usr/local/sbin/ucarp
        /usr/local/sbin/ucarp-down
        /usr/local/sbin/ucarp-up
        /usr/local/share/licenses/ucarp-1.5.2.20171201/ISC
        /usr/local/share/licenses/ucarp-1.5.2.20171201/LICENSE
        /usr/local/share/licenses/ucarp-1.5.2.20171201/catalog.mk

node0a # cp /usr/local/sbin/ucarp-up /usr/local/etc/ucarp/100-up.sh

node0a # cp /usr/local/sbin/ucarp-down /usr/local/etc/ucarp/100-down.sh

The node01a config /etc/rc.conf file related to UCARP config is below – all the other options are default and standardized – I also added hostname and networking information for clarity.

hostname="node01a.local"
ifconfig_vtnet0="inet 192.168.0.11/24"
ifconfig_vtnet1="up"
ucarp_enable="YES"
ucarp_preempt="YES"
ucarp_shutdown="YES"
ucarp_src="192.168.0.11"
ucarp_addr="192.168.0.100"
ucarp_if="vtnet0"
ucarp_pass="S3CUREcarp"
ucarp_vhid="100"
ucarp_upscript="/usr/local/etc/ucarp/100-up.sh"
ucarp_downscript="/usr/local/etc/ucarp/100-down.sh"

The node01b config /etc/rc.conf file related to UCARP config below.

hostname="node01b.local"
ifconfig_vtnet0="inet 192.168.0.12/24"
ifconfig_vtnet1="up"
ucarp_enable="YES"
ucarp_preempt="YES"
ucarp_shutdown="YES"
ucarp_src="192.168.0.12"
ucarp_addr="192.168.0.100"
ucarp_if="vtnet0"  
ucarp_pass="S3CUREcarp"
ucarp_vhid="100"
ucarp_upscript="/usr/local/etc/ucarp/100-up.sh"
ucarp_downscript="/usr/local/etc/ucarp/100-down.sh"

Now – the UCARP needs the ‘UP’ and ‘DOWN’ scripts – the ‘UP’ scripts are the same on both nodes but the ‘DOWN’ scripts are different because they bring back the ‘local’ MAC after stepping down from the ‘master’ role. The

The /usr/local/etc/ucarp/100-up.sh for both node01a and node01b hosts below.

#! /bin/sh

if [ -z "${1}" -o -z "${2}" ]
then
  cat <<EOF
Usage: ${0##*/} interface virtual-address [if-keep-ip]
  interface        - interface name where virtual IP-address to be assigned;
  virtual-address  - virtual IP-address;
  if-keep-ip       - interface name where virtual IP-address should be kept
                     when ucarp changes state to BACKUP;

EOF
  exit 255
fi

exec 2> /dev/null

if [ ! -z "${3}" ]
then
  /sbin/ifconfig "${3}" -alias "${2}"
fi

/sbin/ifconfig "${1}" alias "${2}" netmask 255.255.255.255

# HA IP AND HA MAC
/sbin/ifconfig vtnet1 ether 58:9c:fc:ff:01:ff
/sbin/ifconfig vtnet1 inet 10.0.0.100/24 up                      
/sbin/route add    default 10.0.0.1
/sbin/route change default 10.0.0.1

The /usr/local/etc/ucarp/100-down.sh for node01a node below.

#! /bin/sh

if [ -z "${1}" -o -z "${2}" ]
then
  cat <<EOF
Usage: ${0##*/} interface virtual-address [if-keep-ip]
  interface        - interface name where virtual IP-address to be assigned;
  virtual-address  - virtual IP-address;
  if-keep-ip       - interface name where virtual IP-address should be kept
                     when ucarp changes state to BACKUP;

EOF
  exit 255
fi

exec 2> /dev/null

/sbin/ifconfig "${1}" -alias "${2}"

# HA IP AND HA MAC - BRING BACK node01a MAC
/sbin/ifconfig vtnet1 ether 58:9c:fc:ff:01:aa
/sbin/ifconfig vtnet1 delete 10.0.0.100

The /usr/local/etc/ucarp/100-down.sh for node01b node.

#! /bin/sh

if [ -z "${1}" -o -z "${2}" ]
then
  cat <<EOF
Usage: ${0##*/} interface virtual-address [if-keep-ip]
  interface        - interface name where virtual IP-address to be assigned;
  virtual-address  - virtual IP-address;
  if-keep-ip       - interface name where virtual IP-address should be kept
                     when ucarp changes state to BACKUP;

EOF
  exit 255
fi

exec 2> /dev/null

/sbin/ifconfig "${1}" -alias "${2}"

# HA IP AND HA MAC - BRING BACK node01b MAC
/sbin/ifconfig vtnet1 ether 58:9c:fc:ff:01:bb
/sbin/ifconfig vtnet1 delete 10.0.0.100

To move the HA IP from the ‘master’ to the ‘backup’ is to execute this command on the ‘master’ host:

node01a # service ucarp restart

This is how ‘master’ networking looks like – its on node01b host this time:

node01b # netstat -Win -f inet
you have mail
Name     Mtu Network         Address          Ipkts Ierrs Idrop     Opkts Oerrs  Coll
vtnet0     - 192.168.0.0/24  192.168.0.12    168965     -     -    263946     -     -
vtnet0     - 192.168.0.0/32  192.168.0.100        0     -     -         0     -     -
vtnet1     - 10.0.0.0/27     10.0.0.100     9496832     -     -  11104229     -     -
lo0        - 127.0.0.0/8     127.0.0.1      7071008     -     -   7071036     -     -

node01b # netstat -Wrn -f inet
Routing tables

Internet:
Destination        Gateway            Flags   Nhop#    Mtu            Netif Expire
default            10.0.0.1           UGS        22   1500           vtnet1
127.0.0.1          link#4             UH          1  16384              lo0
10.0.0.0/27        link#3             U           7   1500           vtnet1
10.0.0.100         link#4             UHS         8  16384              lo0
192.168.0.0/24     link#1             U           2   1500           vtnet0
192.168.0.100      link#4             UH          6  16384              lo0
192.168.0.12       link#4             UHS         3  16384              lo0

This is how ‘backup’ networking looks like – its on node01a host this time::

node01a # netstat -Win -f inet
Name     Mtu Network          Address          Ipkts Ierrs Idrop     Opkts Oerrs  Coll
vtnet0     - 192.168.0.0/24   192.168.0.11     61863     -     -     53986     -     -
lo0        - 127.0.0.0/8      127.0.0.1     11944793     -     -  11944848     -     -

node01a # netstat -Wrn -f inet
Routing tables

Internet:
Destination        Gateway            Flags   Nhop#    Mtu            Netif Expire
127.0.0.1          link#4             UH          1  16384              lo0
192.168.0.0/24     link#1             U           2   1500           vtnet0
192.168.0.11       link#4             UHS         3  16384              lo0

Nothing special in that custom config to be honest – but maybe someone will find that useful.

EOF
Top

FreeBSD 14.5-BETA2 Available

Post by FreeBSD Newsflash via FreeBSD News Flash »

The second BETA build for the FreeBSD 14.5 release cycle is now available. ISO images for the amd64, i386, armv7, aarch64, powerpc, powerpcspe, powerpc64, powerpc64le, and riscv64 architectures are FreeBSD mirror sites.
Top

Who’s Tracking You? Use This New Service to Find Out

Post by Brian Krebs via Krebs on Security »

It can be daunting to determine who’s responsible for showing ads on the websites we visit, or who’s harvesting data from the mobile apps we use every day. That information is already semi-public, but it is not easily parsed and traditionally much of it has remained walled away in the hands of large advertising platforms. Not anymore: A powerful and free new service called DecryptAds scrapes and correlates this adtech data and makes it simple to quickly learn a great deal about the entities that are tracking you.

A Decryptads summary of the advertising partnerships declared by espn.com.

The newly launched decryptads.com says it is constantly scraping the files that websites and apps make publicly available to disclose the companies that are permitted to run ads or collect user data. These files include:

ads.txt: all of the adtech companies and data brokers that may run ads or harvest data from the site;
app-ads.txt: entities that can harvest data from or display ads on mobile and smart TV apps;
buyers.json/sellers.json: the entities buying, selling or reselling ad inventory for a given site or app.

Zach Edwards is chief research officer for DecryptAds and a threat researcher at the security company Infoblox. Edwards said he and two other founders decided the service was needed because the adtech data in these files is generally only useful when it can be cross-referenced to build a more complete picture of the advertising ecosystem for each website or app.

“It’s an adtech tool but we’re trying to approach adtech from a security perspective,” Edwards said. “It’s really built for a lot of privacy and security use cases that have been dramatically underserved.”

Those use cases, he said, include tracking down the source of malicious ads that try to foist malware on targeted users, identifying ad networks located in adversarial nations, and detecting the fast growing swarms of AI-generated slop websites and apps. And as decryptads.com demonstrates, these potential security and privacy threats are near impossible to detect just by viewing a single apps.txt or app-ads.txt file.

“Supply-chain integrity issues rarely live in a single file,” the site explains. “They show up as broken cross-references between ads.txt, app-ads.txt, and sellers.json files; as cloned declaration sets across unrelated domains; as seller removals that only make sense when viewed across exchanges; and even as supply paths in bid logs that never actually appear in any given publisher’s authorized-seller list.”

A search in DecryptAds for the hugely popular sports network espn.com reveals 143 ad partners and 19 registered data broker domains are listed within its ads.txt and app-ads.txt files. That data broker information is gradually becoming available because four states — California, Oregon, Texas and Vermont — have recently passed laws requiring data brokers to register if they buy or sell data on consumers from those states. DecryptAds reports that almost half of those data brokers are collecting geolocation data from espn.com visitors who aren’t blocking ads, while another three disclose that they collect device fingerprints and sensitive personal information.

A visual representation of the complex ad supply chain declared by espn.com. Image: decryptads.com.

HIGH-RISK AD PARTNERS

DecryptAds also makes it easy to learn the beneficiaries and national origins of the advertising firms lurking in apps and websites, displaying a conspicuous warning when adtech partners of an app or website are based in “geo-risk” areas like China and Russia, or in countries with strong financial and political ties to both — such as Cyprus and the United Arab Emirates (UAE).

According to DecryptAds, espn.com works with four different advertising entities that are based in either Russia, China or the UAE, including the adtech firm Between Digital, which lists a New York address. However, the dossier on Between Digital flags them as a Russian firm, showing that their publisher offers (PDF) are processed through Alfa Bank, Russia’s largest private commercial bank and one of several financial institutions placed under U.S. sanctions in 2022 after Russia invaded Ukraine. KrebsOnSecurity sought comment from both Between Digital and the company’s founder, and will update this story in the event that either replies.

A search for several top U.S. military news websites — including armytimes.com, airforcetimes.com, defensenews.com, navytimes.com, marinecorpstimes.com and federaltimes.com — shows they all allow Between Digital to serve ads and track users, as well as two entities in the UAE and another in the ownership secrecy haven of Panama. DecryptAds reports that Between Digital is collecting ad data on approximately 55,000 partner websites.

The “Geo Risk” section of decryptads.com.

Pivoting on Between Digital’s app-ads.txt file reveals hundreds of domains featuring simple web-based games that are frequently interrupted by ads. Edwards said Between Digital’s own declarations show the company is listed as both a publisher and a reseller on approximately two-thirds of their portfolio.

“It means they are basically playing both sides of the bidding equation, which creates opportunities to direct client spend at your owned and operated properties or client infrastructure, essentially creating opportunities for conflicts of interest,” Edwards told KrebsOnSecurity. “The problem we have right now is that for years we’ve had almost no one policing these ads.txt and app-ads.txt files.”

The Opera Web browser remains quite popular, and probably many users are unaware that since 2016 it has been majority owned and controlled by the Chinese company Kunlun Tech (the operational headquarters of Opera remain in Oslo, Norway).

Opera.com’s profile at DecryptAds identifies 27 registered data brokers collecting information, including 15 adtech partners in the UAE, six in China, three in Cyprus, two in Russia and one each in Hong Kong and Ukraine. DecryptAds makes clear, however, that these companies represent just seven percent of the adtech partners specified in Opera.com’s ads.txt and app-ads.txt files.

LEGAL DOSSIERS

One feature of DecryptAds that sent this author down multiple hours-long research rabbit holes is its Legal Dossier lookup, which takes several minutes for each search but eventually churns out oodles of useful information about who owns a particular domain or app, when it was registered, and any aliases or relationships it may have to adtech companies and other websites or apps.

For example, last month KrebsOnSecurity wrote about researchers from Bitsight who found that an extremely popular line of TV streaming sticks called H96 quietly rent out each user’s Internet connection to strangers. Bitsight also discovered that when these devices aren’t being used to stream pirated video content, they are spoofing themselves as mobile phones clicking ads on AI-generated slop websites.

Bitsight concluded that the same Chinese company that made several of the malicious apps common to all of these H96 streaming sticks — the Fengwo Group — also also ran the network of ads and AI slop websites being clicked on by tens of thousands of these devices that are pretending to be mobile phones.

Examples of ad landing pages linked to the Fengwo Group. These sites were designed to show ads only to H96 devices that were spoofing their device type as mobile phones. Image: Bitsight.

A DecryptAds legal dossier on the (now dormant) Fengwo Group domain name for the AI slop website pictured on the left in the screenshot above (medicalbeautyhub dot com) shows it shares a seller ID (1674071) with a gaming website — giacoloredstones[.]com — which features yet another seller ID (103488000).

Pivoting on that latter seller ID reveals hundreds of active websites within Russia’s Yandex ad system featuring extremely low-quality games or simple utilities that pepper visitors with ads.

QUIET REMOVALS

Edwards said that when advertising networks suspect a given advertiser is engaged in unauthentic clicks or displaying malicious ads, very often those networks will quietly remove the offender from their list of approved partners without letting anyone else know about their suspicions.

This practice, he said, makes it easier for dodgy adtech firms to avoid accountability and continue victimizing others. To address that visibility gap, DecryptAds features a quiet removals feed that records and correlates all of the sellers.json removals across ad exchanges for the same seller domain or name.

A screenshot of the Quiet Removals Feed at decryptads.com.

“The way the adtech industry works, someone will write a report about ad fraud and only share it with their own clients and they won’t make it public,” Edwards said. “The ban is just removing them from the sellers.json file, but they told nobody. One day it was there, the next it was gone. So if you’re trying to navigate who is suspicious, that’s usually tough to do because there are a lot of adtech companies removing things all at once.”

MALVERTISING AND AI SLOP

Malvertising, the term given to the practice of inserting malicious ads that foist malware or redirect visitors to phishing pages, remains an all-too-frequent occurrence in the modern adtech industry. But Edwards said these malicious ads are far more commonly found now on newly generated AI slop websites than on high traffic destinations that typically employ a variety of technologies and third party tools to quickly flag bad ads.

“None of these slop AI content farms are paying for that kind of protection,” he said. “They’re just signing up the lowest quality partners, and it essentially becomes a greased rail to target the users of those sites with malicious ads. Most malvertising attacks don’t happen on espn.com or huffpost.com, but rather [on] some lower quality content farm and someone just went there because it came up in a search.”

Edwards said the AI slop websites are populated with machine-generated blog posts and images, and cover a wide array of themes from home improvement and decorating to food recipes, hunting, cars and consumer technology. He said organizations that get hit with malicious ads are often at a loss for what to do next, unaware that in most cases the answer is one of the entities listed inside the website’s ads.txt or app-ads.txt file.

“A lot of serious organizations are starting to understand that if we’re not breaking down this ad data, we’re not going to know who’s targeting government people with zero-click payloads on an almost daily basis,” he said.

Edwards maintains that truly getting a handle on the malvertising and AI slop problems will require more data-sharing by the major ad networks. Specifically, he says those platforms do not broadly share what’s known as the “supply chain object” or SCO, structured data attached to each advertising bid request that lets buyers see every seller, reseller and intermediary involved in passing an ad impression from the publisher to the final buyer.

“That SCO tells you who sold it or resold it, and who was the final entity that bought the impression that served that malware payload,” Edwards explained. “You may see the malicious zero-click redirection, but without the supply chain object — which is only served server side — you won’t know who targeted your people with malware and won’t have a way to try and prevent it properly. But if we can encourage the adtech industry to expose that SCO, it will get easier to find the culprit behind any one bad ad.”

DecryptAds also offers an application programming interface (API) that allows researchers to automate queries and integrate the site’s functionality into popular AI platforms.

WHAT CAN YOU DO?

The only sane reaction to the examples described above is to block all online ads outright. This approach is broadly endorsed by security experts because it also makes it more difficult for adtech firms and data brokers to build detailed profiles on you and track your movements around the web and in the real world.

However, much depends on how you normally prefer to browse the Internet, and how much trust you place in third party browser plugins and extensions. For those primarily surfing via a regular desktop or laptop Web browser, uBlock Origin Lite is an excellent free and well-maintained open source option. uBlock Origin also should work with mobile browsers like Firefox, but apparently only on Android-based devices.

Adblock Plus is a decent option for iPhone and iPad users. For power users, Adblock and uBlock Origin both support custom blocking rules from easylist.to, which publishes a frequently updated list that removes most advertisements from webpages.

The well established browser extension NoScript blocks all non-approved Javascript code, and it generally does a fine job blocking most ads from loading. However, script blockers like NoScript may not be suitable for average users who don’t enjoy constantly having to referee which scripts should be allowed to load so that each site displays properly.

More technically inclined/adventuresome readers should strongly consider a hardware approach to blocking ads at the local network level, because that is easily the cheapest, most secure and scalable way to do it. A tiny, low-cost and broadly available computer known as a Raspberry Pi can be turned into a powerful ad blocker for all devices on a local network when fitted with a microSD memory card and a free program called Pi-hole. Once you’ve set it up properly and changed your router’s network settings to use the Pi-hole’s DNS sinkhole and DHCP servers, it should prevent ads from displaying on any devices connected to that network.

Bear in mind that ad blockers often do little to block ads and/or tracking that occurs from within mobile apps that users have chosen to install on their devices. Many websites now push users to install a mobile app, supposedly in order to more fully access and enjoy the site’s services and content. But in my experience, they’re not doing this because the user experience is somehow way better on the app (as LinkedIn tries to convince us non-app users several times a week via email). On the contrary, I find most mobile apps to be horribly designed, annoying, and/or completely unnecessary, and when given the option I will almost always choose to interact with a website or service directly in a Web browser.

No, the cold truth is that big web destinations tend to get pushy with their apps because they make it easier for these companies to keep you on their platforms longer and to collect (and in many cases resell) far more precise data about who, what and where their users are. Also, companies pushing customers the hardest to install mobile apps always seem to liberally opt everyone in to having their data used to train large language models these days. So be cautious about the apps you install on your mobile devices (including any smart TVs!), and poke around their listings at DecryptAds if you want to learn more about their privacy practices and any relationships they may have to adtech firms.

Top

FreeBSD – /etc/pam.d/sshd was updated/overwritten – no merge attempt

Post by Dan Langille via Dan Langille's Other Diary »

I was wondering why hare did not seem to be working anymore.

FYI, this bug report was created before I did this work: pkgbase upgrade to 15.1 restores default /etc/pam.d/* configuration

I tracked it down to a missing line in /etc/pam.d/sshd.

The file is there in this snapshot:

[12:24 r730-01 dvl /jails/serpico/.zfs/snapshot] % diff -ruN autosnap_2026-08-04_00:00:18_daily/etc/pam.d/sshd /jails/serpico/etc/pam.d/sshd
--- autosnap_2026-08-04_00:00:18_daily/etc/pam.d/sshd	2023-12-03 16:38:51.359135000 +0000
+++ /jails/serpico/etc/pam.d/sshd	2026-06-12 09:42:15.000000000 +0000
@@ -21,4 +21,3 @@
 # password
 #password	sufficient	pam_krb5.so		no_warn try_first_pass
 password	required	pam_unix.so		no_warn try_first_pass
-session		optional	pam_exec.so		/usr/local/sbin/hare 10.55.0.10
[12:25 r730-01 dvl /jails/serpico/.zfs/snapshot] % 

It is gone the next day:

[12:24 r730-01 dvl /jails/serpico/.zfs/snapshot] % diff -ruN autosnap_2026-08-05_00:00:20_daily/etc/pam.d/sshd /jails/serpico/etc/pam.d/sshd
[12:24 r730-01 dvl /jails/serpico/.zfs/snapshot] % 

It is also there in this snapshot:

[12:28 r730-01 dvl /jails/serpico/.zfs/snapshot] % diff -ruN mkjail-2026-08-04-14:17:37/etc/pam.d/sshd /jails/serpico/etc/pam.d/sshd
--- mkjail-2026-08-04-14:17:37/etc/pam.d/sshd	2026-07-29 05:09:12.000000000 +0000
+++ /jails/serpico/etc/pam.d/sshd	2026-06-12 09:42:15.000000000 +0000
@@ -21,4 +21,3 @@
 # password
 #password	sufficient	pam_krb5.so		no_warn try_first_pass
 password	required	pam_unix.so		no_warn try_first_pass
-session		optional	pam_exec.so		/usr/local/sbin/hare 10.55.0.10
[12:29 r730-01 dvl /jails/serpico/.zfs/snapshot] % 

I suspect the upgrade to FreeBSD 15.1 dropped that line.

Adding the line back into that file restores the previous behavior.

Now I wonder what else has been removed and how to avoid this in future upgrade.

kevans asked for this after mentioning: It does try a three-way merge, but if that fails then it’s supposed to install the ‘new’ version as foo.pkgnew and let you reconcile the differences

[22:05 r730-01 dvl ~] % ls -l /jails/*/etc/pam.d/sshd.pkg{new,save}
zsh: no matches found: /jails/*/etc/pam.d/sshd.pkgnew

None found on any of the hosts.

I also checked for /jails/*/etc/pam.d/sshd* – only the sshd file was found.

Top

Attempting to reproduce the missing etcmerge from 15.0 to 15.1 upgrade

Post by Dan Langille via Dan Langille's Other Diary »

This post documents my attempt to reproduce the problem outlined in FreeBSD – /etc/pam.d/sshd was updated/overwritten – no merge attempt

FYI, this bug report was created before I did this work: pkgbase upgrade to 15.1 restores default /etc/pam.d/* configuration

I have a working test jail: testingmerge

Snapshot of 15.0

[12:11 r730-03 dvl /usr/local/share] % zfs list | grep testingmerge
data01/jails/testingmerge                      374M  7.62T   374M  /jails/testingmerge
[12:16 r730-03 dvl /usr/local/share] % sudo zfs snapshot data01/jails/testingmerge@clean-15.0
[12:16 r730-03 dvl /usr/local/share] % 

The jail configuration is simple:

testingmerge {
    host.hostname = "testingmerge";
    ip4.addr = 10.55.0.90;
    persist;
}

Not shown

Get the jail started.

I also did, but not critical to reproducing the problem
Enable and start ssh.
Add a user for ssh testing

Alter /etc/pam.d/sshd

Add the following to the end of /etc/pam.d/sshd – for testing I think any line will do, even a comment.

session         optional        pam_exec.so             /usr/local/sbin/hare 10.55.0.10

Even if you don’t install that binary, an ssh login will generate this message:

dvl@testingmerge:~ $ tail -1 /var/log/messages
Aug 12 12:37:28 testingmerge sshd-session[80848]: in _pam_exec(): pam_sm_open_session: execve(/usr/local/sbin/hare): No such file or directory

pkgbasify the jail

I’m following Running pkgbasify on a FreeBSD 15.0 host to convert a jail – the main difference: the host is now a running FreeBSD 15.1

[12:39 r730-03 dvl ~/bin] % sudo zfs snapshot data01/jails/testingmerge@before.pkgbasify
[12:39 r730-03 dvl ~/bin] % 

Then I followed the article to get a pkgbase jail.

Post pkgbasify, the file is unchanged

After:

[12:43 r730-03 dvl ~/bin] % sudo pkg -j testingmerge  which /usr/bin/uname

/usr/bin/uname was installed by package FreeBSD-runtime-15.0p12

After login, I get:

dvl@testingmerge:~ $ tail -1 /var/log/messages
Aug 12 12:42:51 testingmerge sshd-session[83412]: in _pam_exec(): pam_sm_open_session: execve(/usr/local/sbin/hare): No such file or directory

Another snapshot

[13:01 r730-03 dvl ~/bin] % sudo zfs snapshot data01/jails/testingmerge@after.pkgbasify
[13:03 r730-03 dvl ~/bin] % 

Update to 15.1

Let’s use this: https://www.freebsd.org/releases/15.1R/upgrading/

As opposed to this Updating a FreeBSD 15.0 jail to FreeBSD 15.1 (via pkgbase) for this.

But first:

[13:03 r730-03 dvl ~/bin] % sudo zfs snapshot data01/jails/testingmerge@before.15.1    
[13:04 r730-03 dvl ~/bin] % 

First: pkg upgrade

[13:05 r730-03 dvl ~/bin] % sudo pkg -j testingmerge upgrade -r FreeBSD-base 
Updating FreeBSD-base repository catalogue...
[testingmerge] Fetching meta.conf: 100%     179 B   0.2 kB/s    00:01    
[testingmerge] Fetching data: 100%    81 KiB  82.5 kB/s    00:01    
Processing entries: 100%
FreeBSD-base repository update completed. 496 packages processed.
FreeBSD-base is up to date.
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.

… this attempt initially failed, then I added allow.chflags & securelevel = -1; and restarted the jail.

[13:10 r730-03 dvl ~/bin] % sudo pkg -j testingmerge -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000 upgrade -r FreeBSD-base
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
FreeBSD-base is up to date.
Checking for upgrades (207 candidates): 100%
Processing candidates (207 candidates): 100%
Checking integrity... done (11 conflicting)
  - FreeBSD-sound-15.1 [FreeBSD-base] conflicts with FreeBSD-rc-15.0 [installed] on /etc/rc.d/mixer
  - FreeBSD-zstd-lib-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p12 [installed] on /usr/lib/libprivatezstd.so.5
  - FreeBSD-atf-15.1 [FreeBSD-base] conflicts with FreeBSD-tests-15.0p12 [installed] on /usr/share/atf/libatf-sh.subr
  - FreeBSD-clang-dev-15.1p1 [FreeBSD-base] conflicts with FreeBSD-lldb-dev-15.0 [installed] on /usr/lib/libprivatelldb.so
  - FreeBSD-zstd-dev-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-15.0p11 [installed] on /usr/include/private/zstd/zstd.h
  - FreeBSD-pam-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p12 [installed] on /etc/pam.d/README
  - FreeBSD-pam-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-15.0p11 [installed] on /usr/lib/pam_chroot.so
  - FreeBSD-zstd-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-15.0p11 [installed] on /usr/bin/unzstd
  - FreeBSD-clang-15.1p2 [FreeBSD-base] conflicts with FreeBSD-lldb-15.0p11 [installed] on /usr/lib/libprivatelldb.so.19
  - FreeBSD-pam-lib-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p12 [installed] on /usr/lib/libpam.so.6
  - FreeBSD-pam-dev-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-15.0p11 [installed] on /usr/include/security/openpam.h
Checking integrity... done (0 conflicting)
The following 214 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	FreeBSD-pam: 15.1 [FreeBSD-base]
	FreeBSD-pam-dev: 15.1 [FreeBSD-base]
	FreeBSD-pam-lib: 15.1 [FreeBSD-base]
	FreeBSD-zstd: 15.1 [FreeBSD-base]
	FreeBSD-zstd-dev: 15.1 [FreeBSD-base]
	FreeBSD-zstd-lib: 15.1 [FreeBSD-base]

Installed packages to be UPGRADED:
	FreeBSD-acct: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-acpi: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-apm: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-at: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-atf: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-atf-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-atf-lib: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-audit: 15.0p10 -> 15.1p2 [FreeBSD-base]
	FreeBSD-audit-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-audit-lib: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-autofs: 15.0 -> 15.1p2 [FreeBSD-base]
	FreeBSD-bhyve: 15.0 -> 15.1p2 [FreeBSD-base]
	FreeBSD-blocklist: 15.0p3 -> 15.1 [FreeBSD-base]
	FreeBSD-blocklist-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-bluetooth: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-bluetooth-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-bluetooth-lib: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-bmake: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-bootloader-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-bsdconfig: 15.0p9 -> 15.1 [FreeBSD-base]
	FreeBSD-bsdinstall: 15.0p9 -> 15.1 [FreeBSD-base]
	FreeBSD-bsnmp: 15.0p11 -> 15.1p1 [FreeBSD-base]
	FreeBSD-bsnmp-dev: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-bzip2-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-caroot: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ccdconfig: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-certctl: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-clang: 15.0p11 -> 15.1p2 [FreeBSD-base]
	FreeBSD-clang-dev: 15.0p11 -> 15.1p1 [FreeBSD-base]
	FreeBSD-clibs: 15.0p11 -> 15.1p2 [FreeBSD-base]
	FreeBSD-clibs-dev: 15.0p11 -> 15.1p2 [FreeBSD-base]
	FreeBSD-clibs-lib32: 15.0p11 -> 15.1p2 [FreeBSD-base]
	FreeBSD-console-tools: 15.0 -> 15.1p2 [FreeBSD-base]
	FreeBSD-cron: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-csh: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ctf: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ctf-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ctf-lib: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ctl: 15.0 -> 15.1p2 [FreeBSD-base]
	FreeBSD-cxgbe-tools: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-devd: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-devmatch: 15.0p2 -> 15.1 [FreeBSD-base]
	FreeBSD-devmatch-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-dhclient: 15.0p8 -> 15.1 [FreeBSD-base]
	FreeBSD-diff3: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-dma: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-dtrace: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-dtrace-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-dwatch: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ee: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-efi-tools: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-efi-tools-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-examples: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-fd: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-fetch: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-fetch-dev: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-firmware-iwm: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-flua: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-flua-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ftp: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-fwget: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-games: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-geom: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-ggate: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-gssd: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-hast: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-hostapd: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-hyperv-tools: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-inetd: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ipf: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ipfw: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-iscsi: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-jail: 15.0p11 -> 15.1p2 [FreeBSD-base]
	FreeBSD-kerberos: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-kerberos-dev: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-kerberos-kdc: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-kerberos-lib: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-kernel-man: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-kyua: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-lib9p: 15.0 -> 15.1p2 [FreeBSD-base]
	FreeBSD-lib9p-dev: 15.0 -> 15.1p2 [FreeBSD-base]
	FreeBSD-libarchive: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-libarchive-dev: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-libbegemot: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libbegemot-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libblocksruntime: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libblocksruntime-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libbsdstat: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libbsdstat-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libcasper: 15.0p9 -> 15.1 [FreeBSD-base]
	FreeBSD-libcasper-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libcompat-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libcompiler_rt-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libcuse: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libcuse-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libdwarf: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libdwarf-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libevent1: 15.0 -> 15.1p2 [FreeBSD-base]
	FreeBSD-libevent1-dev: 15.0 -> 15.1p2 [FreeBSD-base]
	FreeBSD-libexecinfo: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libexecinfo-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libipt: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libipt-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libldns: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-libldns-dev: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-libmagic: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libmagic-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libmilter: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-libmilter-dev: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-libpathconv: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libpathconv-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-librpcsec_gss: 15.0p5 -> 15.1 [FreeBSD-base]
	FreeBSD-librpcsec_gss-dev: 15.0p5 -> 15.1 [FreeBSD-base]
	FreeBSD-librss: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-librss-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libsqlite3: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libsqlite3-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libthread_db: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libthread_db-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libucl: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libucl-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libvgl: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libvgl-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libvmmapi: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libvmmapi-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libyaml: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-libyaml-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-lld: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-lldb: 15.0p11 -> 15.1 [FreeBSD-base]
	FreeBSD-local-unbound: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-local-unbound-dev: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-locales: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-lp: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-mandoc: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-mlx-tools: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-mtree: 15.0p12 -> 15.1p2 [FreeBSD-base]
	FreeBSD-natd: 15.0p11 -> 15.1p1 [FreeBSD-base]
	FreeBSD-natd-dev: 15.0p11 -> 15.1p1 [FreeBSD-base]
	FreeBSD-ncurses: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ncurses-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ncurses-lib: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-netmap: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-netmap-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-newsyslog: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-nfs: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ntp: 15.0p10 -> 15.1p2 [FreeBSD-base]
	FreeBSD-nuageinit: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-nvme-tools: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-openssl: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-openssl-dev: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-openssl-lib: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-periodic: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-pf: 15.0p5 -> 15.1 [FreeBSD-base]
	FreeBSD-pf-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-pkg-bootstrap: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-pmc: 15.0p11 -> 15.1p2 [FreeBSD-base]
	FreeBSD-pmc-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-powerd: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ppp: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-quotacheck: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-rc: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-rcmds: 15.0p9 -> 15.1 [FreeBSD-base]
	FreeBSD-rdma: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-rescue: 15.0p11 -> 15.1p1 [FreeBSD-base]
	FreeBSD-resolvconf: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-rip: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-runtime: 15.0p12 -> 15.1p2 [FreeBSD-base]
	FreeBSD-runtime-dev: 15.0p11 -> 15.1p1 [FreeBSD-base]
	FreeBSD-sendmail: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-set-base: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-set-devel: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-set-minimal: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-set-optional: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-set-tests: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-smbutils: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-smbutils-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-sound: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-sound-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ssh: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-ssh-dev: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-syscons-data: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-syslogd: 15.0p10 -> 15.1p2 [FreeBSD-base]
	FreeBSD-tcpd: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-tcpd-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-telnet: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-tests: 15.0p12 -> 15.1p2 [FreeBSD-base]
	FreeBSD-tests-dbg: 15.0p11 -> 15.1p2 [FreeBSD-base]
	FreeBSD-toolchain: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-toolchain-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ufs: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ufs-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-ufs-lib: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-utilities: 15.0p11 -> 15.1p2 [FreeBSD-base]
	FreeBSD-utilities-dev: 15.0p11 -> 15.1p1 [FreeBSD-base]
	FreeBSD-vi: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-vt-data: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-wpa: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-xz: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-xz-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-xz-lib: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-yp: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-zfs: 15.0p10 -> 15.1 [FreeBSD-base]
	FreeBSD-zfs-dev: 15.0p11 -> 15.1p1 [FreeBSD-base]
	FreeBSD-zfs-lib: 15.0p11 -> 15.1p1 [FreeBSD-base]
	FreeBSD-zlib: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-zlib-dev: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-zoneinfo: 15.0p12 -> 15.1p2 [FreeBSD-base]

Installed packages to be REMOVED:
	FreeBSD-lldb-dev: 15.0

Number of packages to be removed: 1
Number of packages to be installed: 6
Number of packages to be upgraded: 207

The operation will free 2 MiB.

Proceed with this action? [y/N]: y
[testingmerge] [  1/219] Upgrading FreeBSD-clibs from 15.0p11 to 15.1p2...
[testingmerge] [  1/219] Extracting FreeBSD-clibs-15.1p2: 100%
[testingmerge] [  2/219] Upgrading FreeBSD-clibs-lib32 from 15.0p11 to 15.1p2...
[testingmerge] [  2/219] Extracting FreeBSD-clibs-lib32-15.1p2: 100%
[testingmerge] [  3/219] Upgrading FreeBSD-cron from 15.0 to 15.1...
[testingmerge] [  3/219] Extracting FreeBSD-cron-15.1: 100%
[testingmerge] [  4/219] Upgrading FreeBSD-devmatch from 15.0p2 to 15.1...
[testingmerge] [  4/219] Extracting FreeBSD-devmatch-15.1: 100%
[testingmerge] [  5/219] Upgrading FreeBSD-efi-tools from 15.0 to 15.1...
[testingmerge] [  5/219] Extracting FreeBSD-efi-tools-15.1: 100%
[testingmerge] [  6/219] Upgrading FreeBSD-fetch from 15.0p10 to 15.1...
[testingmerge] [  6/219] Extracting FreeBSD-fetch-15.1: 100%
[testingmerge] [  7/219] Upgrading FreeBSD-firmware-iwm from 15.0 to 15.1...
[testingmerge] [  7/219] Extracting FreeBSD-firmware-iwm-15.1: 100%
[testingmerge] [  8/219] Upgrading FreeBSD-fwget from 15.0 to 15.1...
[testingmerge] [  8/219] Extracting FreeBSD-fwget-15.1: 100%
[testingmerge] [  9/219] Upgrading FreeBSD-geom from 15.0p10 to 15.1...
[testingmerge] [  9/219] Extracting FreeBSD-geom-15.1: 100%
[testingmerge] [ 10/219] Upgrading FreeBSD-hyperv-tools from 15.0 to 15.1...
[testingmerge] [ 10/219] Extracting FreeBSD-hyperv-tools-15.1: 100%
[testingmerge] [ 11/219] Upgrading FreeBSD-kernel-man from 15.0 to 15.1...
[testingmerge] [ 11/219] Extracting FreeBSD-kernel-man-15.1: 100%
[testingmerge] [ 12/219] Upgrading FreeBSD-locales from 15.0 to 15.1...
[testingmerge] [ 12/219] Extracting FreeBSD-locales-15.1: 100%
[testingmerge] [ 13/219] Upgrading FreeBSD-mandoc from 15.0 to 15.1...
[testingmerge] [ 13/219] Extracting FreeBSD-mandoc-15.1: 100%
[testingmerge] [ 14/219] Upgrading FreeBSD-ncurses from 15.0 to 15.1...
[testingmerge] [ 14/219] Extracting FreeBSD-ncurses-15.1: 100%
[testingmerge] [ 15/219] Upgrading FreeBSD-ncurses-lib from 15.0 to 15.1...
[testingmerge] [ 15/219] Extracting FreeBSD-ncurses-lib-15.1: 100%
[testingmerge] [ 16/219] Upgrading FreeBSD-newsyslog from 15.0 to 15.1...
[testingmerge] [ 16/219] Extracting FreeBSD-newsyslog-15.1: 100%
[testingmerge] [ 17/219] Upgrading FreeBSD-periodic from 15.0 to 15.1...
[testingmerge] [ 17/219] Extracting FreeBSD-periodic-15.1: 100%
[testingmerge] [ 18/219] Upgrading FreeBSD-pkg-bootstrap from 15.0p10 to 15.1...
[testingmerge] [ 18/219] Extracting FreeBSD-pkg-bootstrap-15.1: 100%
[testingmerge] [ 19/219] Upgrading FreeBSD-powerd from 15.0 to 15.1...
[testingmerge] [ 19/219] Extracting FreeBSD-powerd-15.1: 100%
[testingmerge] [ 20/219] Upgrading FreeBSD-ppp from 15.0 to 15.1...
[testingmerge] [ 20/219] Extracting FreeBSD-ppp-15.1: 100%
[testingmerge] [ 21/219] Upgrading FreeBSD-rescue from 15.0p11 to 15.1p1...
[testingmerge] [ 21/219] Extracting FreeBSD-rescue-15.1p1: 100%
[testingmerge] [ 22/219] Upgrading FreeBSD-resolvconf from 15.0 to 15.1...
[testingmerge] [ 22/219] Extracting FreeBSD-resolvconf-15.1: 100%
[testingmerge] [ 23/219] Upgrading FreeBSD-dhclient from 15.0p8 to 15.1...
[testingmerge] [ 23/219] Extracting FreeBSD-dhclient-15.1: 100%
[testingmerge] [ 24/219] Upgrading FreeBSD-runtime from 15.0p12 to 15.1p2...
[testingmerge] [ 24/219] Extracting FreeBSD-runtime-15.1p2: 100%
[testingmerge] [ 25/219] Upgrading FreeBSD-at from 15.0 to 15.1...
[testingmerge] [ 25/219] Extracting FreeBSD-at-15.1: 100%
[testingmerge] [ 26/219] Upgrading FreeBSD-devd from 15.0 to 15.1...
[testingmerge] [ 26/219] Extracting FreeBSD-devd-15.1: 100%
[testingmerge] [ 27/219] Installing FreeBSD-pam-lib-15.1...
[testingmerge] [ 27/219] Extracting FreeBSD-pam-lib-15.1: 100%
[testingmerge] [ 28/219] Upgrading FreeBSD-syslogd from 15.0p10 to 15.1p2...
[testingmerge] [ 28/219] Extracting FreeBSD-syslogd-15.1p2: 100%
[testingmerge] [ 29/219] Upgrading FreeBSD-ufs from 15.0 to 15.1...
[testingmerge] [ 29/219] Extracting FreeBSD-ufs-15.1: 100%
[testingmerge] [ 30/219] Upgrading FreeBSD-ufs-lib from 15.0 to 15.1...
[testingmerge] [ 30/219] Extracting FreeBSD-ufs-lib-15.1: 100%
[testingmerge] [ 31/219] Upgrading FreeBSD-utilities from 15.0p11 to 15.1p2...
[testingmerge] [ 31/219] Extracting FreeBSD-utilities-15.1p2: 100%
[testingmerge] [ 32/219] Installing FreeBSD-pam-15.1...
[testingmerge] [ 32/219] Extracting FreeBSD-pam-15.1: 100%
[testingmerge] [ 33/219] Upgrading FreeBSD-vi from 15.0 to 15.1...
[testingmerge] [ 33/219] Extracting FreeBSD-vi-15.1: 100%
[testingmerge] [ 34/219] Upgrading FreeBSD-vt-data from 15.0 to 15.1...
[testingmerge] [ 34/219] Extracting FreeBSD-vt-data-15.1: 100%
[testingmerge] [ 35/219] Upgrading FreeBSD-wpa from 15.0p10 to 15.1...
[testingmerge] [ 35/219] Extracting FreeBSD-wpa-15.1: 100%
[testingmerge] [ 36/219] Upgrading FreeBSD-zfs from 15.0p10 to 15.1...
[testingmerge] [ 36/219] Extracting FreeBSD-zfs-15.1: 100%
[testingmerge] [ 37/219] Upgrading FreeBSD-zfs-lib from 15.0p11 to 15.1p1...
[testingmerge] [ 37/219] Extracting FreeBSD-zfs-lib-15.1p1: 100%
[testingmerge] [ 38/219] Upgrading FreeBSD-zlib from 15.0 to 15.1...
[testingmerge] [ 38/219] Extracting FreeBSD-zlib-15.1: 100%
[testingmerge] [ 39/219] Upgrading FreeBSD-zoneinfo from 15.0p12 to 15.1p2...
[testingmerge] [ 39/219] Extracting FreeBSD-zoneinfo-15.1p2: 100%
[testingmerge] [ 40/219] Installing FreeBSD-zstd-15.1...
[testingmerge] [ 40/219] Extracting FreeBSD-zstd-15.1: 100%
[testingmerge] [ 41/219] Installing FreeBSD-zstd-lib-15.1...
[testingmerge] [ 41/219] Extracting FreeBSD-zstd-lib-15.1: 100%
[testingmerge] [ 42/219] Deinstalling FreeBSD-set-tests-15.0...
[testingmerge] [ 43/219] Deinstalling FreeBSD-tests-dbg-15.0p11...
[testingmerge] [ 43/219] Deleting files for FreeBSD-tests-dbg-15.0p11: 100%
[testingmerge] [ 44/219] Deinstalling FreeBSD-set-base-15.0...
[testingmerge] [ 45/219] Deinstalling FreeBSD-set-devel-15.0...
[testingmerge] [ 46/219] Upgrading FreeBSD-bmake from 15.0 to 15.1...
[testingmerge] [ 46/219] Extracting FreeBSD-bmake-15.1: 100%
[testingmerge] [ 47/219] Upgrading FreeBSD-bootloader-dev from 15.0 to 15.1...
[testingmerge] [ 47/219] Extracting FreeBSD-bootloader-dev-15.1: 100%
[testingmerge] [ 48/219] Upgrading FreeBSD-bzip2-dev from 15.0 to 15.1...
[testingmerge] [ 48/219] Extracting FreeBSD-bzip2-dev-15.1: 100%
[testingmerge] [ 49/219] Upgrading FreeBSD-clibs-dev from 15.0p11 to 15.1p2...
[testingmerge] [ 49/219] Extracting FreeBSD-clibs-dev-15.1p2: 100%
[testingmerge] [ 50/219] Upgrading FreeBSD-ctf from 15.0 to 15.1...
[testingmerge] [ 50/219] Extracting FreeBSD-ctf-15.1: 100%
[testingmerge] [ 51/219] Upgrading FreeBSD-ctf-dev from 15.0 to 15.1...
[testingmerge] [ 51/219] Extracting FreeBSD-ctf-dev-15.1: 100%
[testingmerge] [ 52/219] Upgrading FreeBSD-ctf-lib from 15.0 to 15.1...
[testingmerge] [ 52/219] Extracting FreeBSD-ctf-lib-15.1: 100%
[testingmerge] [ 53/219] Upgrading FreeBSD-devmatch-dev from 15.0 to 15.1...
[testingmerge] [ 53/219] Extracting FreeBSD-devmatch-dev-15.1: 100%
[testingmerge] [ 54/219] Upgrading FreeBSD-efi-tools-dev from 15.0 to 15.1...
[testingmerge] [ 54/219] Extracting FreeBSD-efi-tools-dev-15.1: 100%
[testingmerge] [ 55/219] Upgrading FreeBSD-fetch-dev from 15.0p10 to 15.1...
[testingmerge] [ 55/219] Extracting FreeBSD-fetch-dev-15.1: 100%
[testingmerge] [ 56/219] Upgrading FreeBSD-kyua from 15.0 to 15.1...
[testingmerge] [ 56/219] Extracting FreeBSD-kyua-15.1: 100%
[testingmerge] [ 57/219] Upgrading FreeBSD-libcompat-dev from 15.0 to 15.1...
[testingmerge] [ 57/219] Extracting FreeBSD-libcompat-dev-15.1: 100%
[testingmerge] [ 58/219] Upgrading FreeBSD-libcompiler_rt-dev from 15.0 to 15.1...
[testingmerge] [ 58/219] Extracting FreeBSD-libcompiler_rt-dev-15.1: 100%
[testingmerge] [ 59/219] Upgrading FreeBSD-lld from 15.0 to 15.1...
[testingmerge] [ 59/219] Extracting FreeBSD-lld-15.1: 100%
[testingmerge] [ 60/219] Deinstalling FreeBSD-lldb-dev-15.0...
[testingmerge] [ 60/219] Deleting files for FreeBSD-lldb-dev-15.0: 100%
[testingmerge] [ 61/219] Upgrading FreeBSD-lldb from 15.0p11 to 15.1...
[testingmerge] [ 61/219] Extracting FreeBSD-lldb-15.1: 100%
[testingmerge] [ 62/219] Upgrading FreeBSD-clang from 15.0p11 to 15.1p2...
[testingmerge] [ 62/219] Extracting FreeBSD-clang-15.1p2: 100%
[testingmerge] [ 63/219] Upgrading FreeBSD-clang-dev from 15.0p11 to 15.1p1...
[testingmerge] [ 63/219] Extracting FreeBSD-clang-dev-15.1p1: 100%
[testingmerge] [ 64/219] Upgrading FreeBSD-mtree from 15.0p12 to 15.1p2...
[testingmerge] [ 64/219] Extracting FreeBSD-mtree-15.1p2: 100%
[testingmerge] [ 65/219] Upgrading FreeBSD-ncurses-dev from 15.0 to 15.1...
[testingmerge] [ 65/219] Extracting FreeBSD-ncurses-dev-15.1: 100%
[testingmerge] [ 66/219] Upgrading FreeBSD-rc from 15.0 to 15.1...
[testingmerge] [ 66/219] Extracting FreeBSD-rc-15.1: 100%
[testingmerge] [ 67/219] Upgrading FreeBSD-runtime-dev from 15.0p11 to 15.1p1...
[testingmerge] [ 67/219] Extracting FreeBSD-runtime-dev-15.1p1: 100%
[testingmerge] [ 68/219] Installing FreeBSD-pam-dev-15.1...
[testingmerge] [ 68/219] Extracting FreeBSD-pam-dev-15.1: 100%
[testingmerge] [ 69/219] Upgrading FreeBSD-toolchain from 15.0 to 15.1...
[testingmerge] [ 69/219] Extracting FreeBSD-toolchain-15.1: 100%
[testingmerge] [ 70/219] Upgrading FreeBSD-toolchain-dev from 15.0 to 15.1...
[testingmerge] [ 70/219] Extracting FreeBSD-toolchain-dev-15.1: 100%
[testingmerge] [ 71/219] Upgrading FreeBSD-ufs-dev from 15.0 to 15.1...
[testingmerge] [ 71/219] Extracting FreeBSD-ufs-dev-15.1: 100%
[testingmerge] [ 72/219] Upgrading FreeBSD-utilities-dev from 15.0p11 to 15.1p1...
[testingmerge] [ 72/219] Extracting FreeBSD-utilities-dev-15.1p1: 100%
[testingmerge] [ 73/219] Upgrading FreeBSD-zfs-dev from 15.0p11 to 15.1p1...
[testingmerge] [ 73/219] Extracting FreeBSD-zfs-dev-15.1p1: 100%
[testingmerge] [ 74/219] Upgrading FreeBSD-zlib-dev from 15.0 to 15.1...
[testingmerge] [ 74/219] Extracting FreeBSD-zlib-dev-15.1: 100%
[testingmerge] [ 75/219] Installing FreeBSD-zstd-dev-15.1...
[testingmerge] [ 75/219] Extracting FreeBSD-zstd-dev-15.1: 100%
[testingmerge] [ 76/219] Deinstalling FreeBSD-set-optional-15.0...
[testingmerge] [ 77/219] Upgrading FreeBSD-acct from 15.0 to 15.1...
[testingmerge] [ 77/219] Extracting FreeBSD-acct-15.1: 100%
[testingmerge] [ 78/219] Upgrading FreeBSD-acpi from 15.0 to 15.1...
[testingmerge] [ 78/219] Extracting FreeBSD-acpi-15.1: 100%
[testingmerge] [ 79/219] Upgrading FreeBSD-apm from 15.0 to 15.1...
[testingmerge] [ 79/219] Extracting FreeBSD-apm-15.1: 100%
[testingmerge] [ 80/219] Upgrading FreeBSD-atf-lib from 15.0 to 15.1...
[testingmerge] [ 80/219] Extracting FreeBSD-atf-lib-15.1: 100%
[testingmerge] [ 81/219] Upgrading FreeBSD-audit from 15.0p10 to 15.1p2...
[testingmerge] [ 81/219] Extracting FreeBSD-audit-15.1p2: 100%
[testingmerge] [ 82/219] Upgrading FreeBSD-audit-dev from 15.0 to 15.1...
[testingmerge] [ 82/219] Extracting FreeBSD-audit-dev-15.1: 100%
[testingmerge] [ 83/219] Upgrading FreeBSD-audit-lib from 15.0 to 15.1...
[testingmerge] [ 83/219] Extracting FreeBSD-audit-lib-15.1: 100%
[testingmerge] [ 84/219] Upgrading FreeBSD-autofs from 15.0 to 15.1p2...
[testingmerge] [ 84/219] Extracting FreeBSD-autofs-15.1p2: 100%
[testingmerge] [ 85/219] Upgrading FreeBSD-bhyve from 15.0 to 15.1p2...
[testingmerge] [ 85/219] Extracting FreeBSD-bhyve-15.1p2: 100%
[testingmerge] [ 86/219] Upgrading FreeBSD-blocklist from 15.0p3 to 15.1...
[testingmerge] [ 86/219] Extracting FreeBSD-blocklist-15.1: 100%
[testingmerge] [ 87/219] Upgrading FreeBSD-blocklist-dev from 15.0 to 15.1...
[testingmerge] [ 87/219] Extracting FreeBSD-blocklist-dev-15.1: 100%
[testingmerge] [ 88/219] Upgrading FreeBSD-bluetooth from 15.0 to 15.1...
[testingmerge] [ 88/219] Extracting FreeBSD-bluetooth-15.1: 100%
[testingmerge] [ 89/219] Upgrading FreeBSD-bluetooth-dev from 15.0 to 15.1...
[testingmerge] [ 89/219] Extracting FreeBSD-bluetooth-dev-15.1: 100%
[testingmerge] [ 90/219] Upgrading FreeBSD-bluetooth-lib from 15.0 to 15.1...
[testingmerge] [ 90/219] Extracting FreeBSD-bluetooth-lib-15.1: 100%
[testingmerge] [ 91/219] Upgrading FreeBSD-bsdconfig from 15.0p9 to 15.1...
[testingmerge] [ 91/219] Extracting FreeBSD-bsdconfig-15.1: 100%
[testingmerge] [ 92/219] Upgrading FreeBSD-bsnmp from 15.0p11 to 15.1p1...
[testingmerge] [ 92/219] Extracting FreeBSD-bsnmp-15.1p1: 100%
[testingmerge] [ 93/219] Upgrading FreeBSD-bsnmp-dev from 15.0p10 to 15.1...
[testingmerge] [ 93/219] Extracting FreeBSD-bsnmp-dev-15.1: 100%
[testingmerge] [ 94/219] Upgrading FreeBSD-ccdconfig from 15.0 to 15.1...
[testingmerge] [ 94/219] Extracting FreeBSD-ccdconfig-15.1: 100%
[testingmerge] [ 95/219] Upgrading FreeBSD-console-tools from 15.0 to 15.1p2...
[testingmerge] [ 95/219] Extracting FreeBSD-console-tools-15.1p2: 100%
[testingmerge] [ 96/219] Upgrading FreeBSD-csh from 15.0 to 15.1...
[testingmerge] [ 96/219] Extracting FreeBSD-csh-15.1: 100%
[testingmerge] [ 97/219] Upgrading FreeBSD-ctl from 15.0 to 15.1p2...
[testingmerge] [ 97/219] Extracting FreeBSD-ctl-15.1p2: 100%
[testingmerge] [ 98/219] Upgrading FreeBSD-cxgbe-tools from 15.0 to 15.1...
[testingmerge] [ 98/219] Extracting FreeBSD-cxgbe-tools-15.1: 100%
[testingmerge] [ 99/219] Upgrading FreeBSD-diff3 from 15.0 to 15.1...
[testingmerge] [ 99/219] Extracting FreeBSD-diff3-15.1: 100%
[testingmerge] [100/219] Upgrading FreeBSD-dma from 15.0p10 to 15.1...
[testingmerge] [100/219] Extracting FreeBSD-dma-15.1: 100%
[testingmerge] [101/219] Upgrading FreeBSD-dtrace from 15.0 to 15.1...
[testingmerge] [101/219] Extracting FreeBSD-dtrace-15.1: 100%
[testingmerge] [102/219] Upgrading FreeBSD-dtrace-dev from 15.0 to 15.1...
[testingmerge] [102/219] Extracting FreeBSD-dtrace-dev-15.1: 100%
[testingmerge] [103/219] Upgrading FreeBSD-dwatch from 15.0 to 15.1...
[testingmerge] [103/219] Extracting FreeBSD-dwatch-15.1: 100%
[testingmerge] [104/219] Upgrading FreeBSD-ee from 15.0 to 15.1...
[testingmerge] [104/219] Extracting FreeBSD-ee-15.1: 100%
[testingmerge] [105/219] Upgrading FreeBSD-examples from 15.0 to 15.1...
[testingmerge] [105/219] Extracting FreeBSD-examples-15.1: 100%
[testingmerge] [106/219] Upgrading FreeBSD-fd from 15.0 to 15.1...
[testingmerge] [106/219] Extracting FreeBSD-fd-15.1: 100%
[testingmerge] [107/219] Upgrading FreeBSD-flua from 15.0 to 15.1...
[testingmerge] [107/219] Extracting FreeBSD-flua-15.1: 100%
[testingmerge] [108/219] Upgrading FreeBSD-bsdinstall from 15.0p9 to 15.1...
[testingmerge] [108/219] Extracting FreeBSD-bsdinstall-15.1: 100%
[testingmerge] [109/219] Upgrading FreeBSD-flua-dev from 15.0 to 15.1...
[testingmerge] [109/219] Extracting FreeBSD-flua-dev-15.1: 100%
[testingmerge] [110/219] Upgrading FreeBSD-ftp from 15.0 to 15.1...
[testingmerge] [110/219] Extracting FreeBSD-ftp-15.1: 100%
[testingmerge] [111/219] Upgrading FreeBSD-games from 15.0 to 15.1...
[testingmerge] [111/219] Extracting FreeBSD-games-15.1: 100%
[testingmerge] [112/219] Upgrading FreeBSD-ggate from 15.0 to 15.1...
[testingmerge] [112/219] Extracting FreeBSD-ggate-15.1: 100%
[testingmerge] [113/219] Upgrading FreeBSD-gssd from 15.0 to 15.1...
[testingmerge] [113/219] Extracting FreeBSD-gssd-15.1: 100%
[testingmerge] [114/219] Upgrading FreeBSD-hast from 15.0 to 15.1...
[testingmerge] [114/219] Extracting FreeBSD-hast-15.1: 100%
[testingmerge] [115/219] Upgrading FreeBSD-hostapd from 15.0p10 to 15.1...
[testingmerge] [115/219] Extracting FreeBSD-hostapd-15.1: 100%
[testingmerge] [116/219] Upgrading FreeBSD-inetd from 15.0 to 15.1...
[testingmerge] [116/219] Extracting FreeBSD-inetd-15.1: 100%
[testingmerge] [117/219] Upgrading FreeBSD-ipf from 15.0 to 15.1...
[testingmerge] [117/219] Extracting FreeBSD-ipf-15.1: 100%
[testingmerge] [118/219] Upgrading FreeBSD-ipfw from 15.0 to 15.1...
[testingmerge] [118/219] Extracting FreeBSD-ipfw-15.1: 100%
[testingmerge] [119/219] Upgrading FreeBSD-iscsi from 15.0 to 15.1...
[testingmerge] [119/219] Extracting FreeBSD-iscsi-15.1: 100%
[testingmerge] [120/219] Upgrading FreeBSD-jail from 15.0p11 to 15.1p2...
[testingmerge] [120/219] Extracting FreeBSD-jail-15.1p2: 100%
[testingmerge] [121/219] Upgrading FreeBSD-kerberos from 15.0 to 15.1...
[testingmerge] [121/219] Extracting FreeBSD-kerberos-15.1: 100%
[testingmerge] [122/219] Upgrading FreeBSD-kerberos-dev from 15.0p10 to 15.1...
[testingmerge] [122/219] Extracting FreeBSD-kerberos-dev-15.1: 100%
[testingmerge] [123/219] Upgrading FreeBSD-kerberos-kdc from 15.0p10 to 15.1...
[testingmerge] [123/219] Extracting FreeBSD-kerberos-kdc-15.1: 100%
[testingmerge] [124/219] Upgrading FreeBSD-kerberos-lib from 15.0p10 to 15.1...
[testingmerge] [124/219] Extracting FreeBSD-kerberos-lib-15.1: 100%
[testingmerge] [125/219] Upgrading FreeBSD-lib9p from 15.0 to 15.1p2...
[testingmerge] [125/219] Extracting FreeBSD-lib9p-15.1p2: 100%
[testingmerge] [126/219] Upgrading FreeBSD-lib9p-dev from 15.0 to 15.1p2...
[testingmerge] [126/219] Extracting FreeBSD-lib9p-dev-15.1p2: 100%
[testingmerge] [127/219] Upgrading FreeBSD-libarchive from 15.0p10 to 15.1...
[testingmerge] [127/219] Extracting FreeBSD-libarchive-15.1: 100%
[testingmerge] [128/219] Upgrading FreeBSD-libarchive-dev from 15.0p10 to 15.1...
[testingmerge] [128/219] Extracting FreeBSD-libarchive-dev-15.1: 100%
[testingmerge] [129/219] Upgrading FreeBSD-libbegemot from 15.0 to 15.1...
[testingmerge] [129/219] Extracting FreeBSD-libbegemot-15.1: 100%
[testingmerge] [130/219] Upgrading FreeBSD-libbegemot-dev from 15.0 to 15.1...
[testingmerge] [130/219] Extracting FreeBSD-libbegemot-dev-15.1: 100%
[testingmerge] [131/219] Upgrading FreeBSD-libblocksruntime from 15.0 to 15.1...
[testingmerge] [131/219] Extracting FreeBSD-libblocksruntime-15.1: 100%
[testingmerge] [132/219] Upgrading FreeBSD-libblocksruntime-dev from 15.0 to 15.1...
[testingmerge] [132/219] Extracting FreeBSD-libblocksruntime-dev-15.1: 100%
[testingmerge] [133/219] Upgrading FreeBSD-libbsdstat from 15.0 to 15.1...
[testingmerge] [133/219] Extracting FreeBSD-libbsdstat-15.1: 100%
[testingmerge] [134/219] Upgrading FreeBSD-libbsdstat-dev from 15.0 to 15.1...
[testingmerge] [134/219] Extracting FreeBSD-libbsdstat-dev-15.1: 100%
[testingmerge] [135/219] Upgrading FreeBSD-libcasper from 15.0p9 to 15.1...
[testingmerge] [135/219] Extracting FreeBSD-libcasper-15.1: 100%
[testingmerge] [136/219] Upgrading FreeBSD-libcasper-dev from 15.0 to 15.1...
[testingmerge] [136/219] Extracting FreeBSD-libcasper-dev-15.1: 100%
[testingmerge] [137/219] Upgrading FreeBSD-libcuse from 15.0 to 15.1...
[testingmerge] [137/219] Extracting FreeBSD-libcuse-15.1: 100%
[testingmerge] [138/219] Upgrading FreeBSD-libcuse-dev from 15.0 to 15.1...
[testingmerge] [138/219] Extracting FreeBSD-libcuse-dev-15.1: 100%
[testingmerge] [139/219] Upgrading FreeBSD-libdwarf from 15.0 to 15.1...
[testingmerge] [139/219] Extracting FreeBSD-libdwarf-15.1: 100%
[testingmerge] [140/219] Upgrading FreeBSD-libdwarf-dev from 15.0 to 15.1...
[testingmerge] [140/219] Extracting FreeBSD-libdwarf-dev-15.1: 100%
[testingmerge] [141/219] Upgrading FreeBSD-libevent1 from 15.0 to 15.1p2...
[testingmerge] [141/219] Extracting FreeBSD-libevent1-15.1p2: 100%
[testingmerge] [142/219] Upgrading FreeBSD-libevent1-dev from 15.0 to 15.1p2...
[testingmerge] [142/219] Extracting FreeBSD-libevent1-dev-15.1p2: 100%
[testingmerge] [143/219] Upgrading FreeBSD-libexecinfo from 15.0 to 15.1...
[testingmerge] [143/219] Extracting FreeBSD-libexecinfo-15.1: 100%
[testingmerge] [144/219] Upgrading FreeBSD-libexecinfo-dev from 15.0 to 15.1...
[testingmerge] [144/219] Extracting FreeBSD-libexecinfo-dev-15.1: 100%
[testingmerge] [145/219] Upgrading FreeBSD-libipt from 15.0 to 15.1...
[testingmerge] [145/219] Extracting FreeBSD-libipt-15.1: 100%
[testingmerge] [146/219] Upgrading FreeBSD-libipt-dev from 15.0 to 15.1...
[testingmerge] [146/219] Extracting FreeBSD-libipt-dev-15.1: 100%
[testingmerge] [147/219] Upgrading FreeBSD-libldns from 15.0p10 to 15.1...
[testingmerge] [147/219] Extracting FreeBSD-libldns-15.1: 100%
[testingmerge] [148/219] Upgrading FreeBSD-libldns-dev from 15.0p10 to 15.1...
[testingmerge] [148/219] Extracting FreeBSD-libldns-dev-15.1: 100%
[testingmerge] [149/219] Upgrading FreeBSD-libmagic from 15.0 to 15.1...
[testingmerge] [149/219] Extracting FreeBSD-libmagic-15.1: 100%
[testingmerge] [150/219] Upgrading FreeBSD-libmagic-dev from 15.0 to 15.1...
[testingmerge] [150/219] Extracting FreeBSD-libmagic-dev-15.1: 100%
[testingmerge] [151/219] Upgrading FreeBSD-libmilter from 15.0p10 to 15.1...
[testingmerge] [151/219] Extracting FreeBSD-libmilter-15.1: 100%
[testingmerge] [152/219] Upgrading FreeBSD-libmilter-dev from 15.0p10 to 15.1...
[testingmerge] [152/219] Extracting FreeBSD-libmilter-dev-15.1: 100%
[testingmerge] [153/219] Upgrading FreeBSD-libpathconv from 15.0 to 15.1...
[testingmerge] [153/219] Extracting FreeBSD-libpathconv-15.1: 100%
[testingmerge] [154/219] Upgrading FreeBSD-libpathconv-dev from 15.0 to 15.1...
[testingmerge] [154/219] Extracting FreeBSD-libpathconv-dev-15.1: 100%
[testingmerge] [155/219] Upgrading FreeBSD-librpcsec_gss from 15.0p5 to 15.1...
[testingmerge] [155/219] Extracting FreeBSD-librpcsec_gss-15.1: 100%
[testingmerge] [156/219] Upgrading FreeBSD-librpcsec_gss-dev from 15.0p5 to 15.1...
[testingmerge] [156/219] Extracting FreeBSD-librpcsec_gss-dev-15.1: 100%
[testingmerge] [157/219] Upgrading FreeBSD-librss from 15.0 to 15.1...
[testingmerge] [157/219] Extracting FreeBSD-librss-15.1: 100%
[testingmerge] [158/219] Upgrading FreeBSD-librss-dev from 15.0 to 15.1...
[testingmerge] [158/219] Extracting FreeBSD-librss-dev-15.1: 100%
[testingmerge] [159/219] Upgrading FreeBSD-libsqlite3 from 15.0 to 15.1...
[testingmerge] [159/219] Extracting FreeBSD-libsqlite3-15.1: 100%
[testingmerge] [160/219] Upgrading FreeBSD-libsqlite3-dev from 15.0 to 15.1...
[testingmerge] [160/219] Extracting FreeBSD-libsqlite3-dev-15.1: 100%
[testingmerge] [161/219] Upgrading FreeBSD-libthread_db from 15.0 to 15.1...
[testingmerge] [161/219] Extracting FreeBSD-libthread_db-15.1: 100%
[testingmerge] [162/219] Upgrading FreeBSD-libthread_db-dev from 15.0 to 15.1...
[testingmerge] [162/219] Extracting FreeBSD-libthread_db-dev-15.1: 100%
[testingmerge] [163/219] Upgrading FreeBSD-libucl from 15.0 to 15.1...
[testingmerge] [163/219] Extracting FreeBSD-libucl-15.1: 100%
[testingmerge] [164/219] Upgrading FreeBSD-libucl-dev from 15.0 to 15.1...
[testingmerge] [164/219] Extracting FreeBSD-libucl-dev-15.1: 100%
[testingmerge] [165/219] Upgrading FreeBSD-libvgl from 15.0 to 15.1...
[testingmerge] [165/219] Extracting FreeBSD-libvgl-15.1: 100%
[testingmerge] [166/219] Upgrading FreeBSD-libvgl-dev from 15.0 to 15.1...
[testingmerge] [166/219] Extracting FreeBSD-libvgl-dev-15.1: 100%
[testingmerge] [167/219] Upgrading FreeBSD-libvmmapi from 15.0 to 15.1...
[testingmerge] [167/219] Extracting FreeBSD-libvmmapi-15.1: 100%
[testingmerge] [168/219] Upgrading FreeBSD-libvmmapi-dev from 15.0 to 15.1...
[testingmerge] [168/219] Extracting FreeBSD-libvmmapi-dev-15.1: 100%
[testingmerge] [169/219] Upgrading FreeBSD-libyaml from 15.0 to 15.1...
[testingmerge] [169/219] Extracting FreeBSD-libyaml-15.1: 100%
[testingmerge] [170/219] Upgrading FreeBSD-libyaml-dev from 15.0 to 15.1...
[testingmerge] [170/219] Extracting FreeBSD-libyaml-dev-15.1: 100%
[testingmerge] [171/219] Upgrading FreeBSD-local-unbound from 15.0p10 to 15.1...
[testingmerge] [171/219] Extracting FreeBSD-local-unbound-15.1: 100%
[testingmerge] [172/219] Upgrading FreeBSD-local-unbound-dev from 15.0p10 to 15.1...
[testingmerge] [172/219] Extracting FreeBSD-local-unbound-dev-15.1: 100%
[testingmerge] [173/219] Upgrading FreeBSD-lp from 15.0 to 15.1...
[testingmerge] [173/219] Extracting FreeBSD-lp-15.1: 100%
[testingmerge] [174/219] Upgrading FreeBSD-mlx-tools from 15.0 to 15.1...
[testingmerge] [174/219] Extracting FreeBSD-mlx-tools-15.1: 100%
[testingmerge] [175/219] Upgrading FreeBSD-natd from 15.0p11 to 15.1p1...
[testingmerge] [175/219] Extracting FreeBSD-natd-15.1p1: 100%
[testingmerge] [176/219] Upgrading FreeBSD-natd-dev from 15.0p11 to 15.1p1...
[testingmerge] [176/219] Extracting FreeBSD-natd-dev-15.1p1: 100%
[testingmerge] [177/219] Upgrading FreeBSD-netmap from 15.0 to 15.1...
[testingmerge] [177/219] Extracting FreeBSD-netmap-15.1: 100%
[testingmerge] [178/219] Upgrading FreeBSD-netmap-dev from 15.0 to 15.1...
[testingmerge] [178/219] Extracting FreeBSD-netmap-dev-15.1: 100%
[testingmerge] [179/219] Upgrading FreeBSD-nfs from 15.0 to 15.1...
[testingmerge] [179/219] Extracting FreeBSD-nfs-15.1: 100%
[testingmerge] [180/219] Upgrading FreeBSD-ntp from 15.0p10 to 15.1p2...
[testingmerge] [180/219] Extracting FreeBSD-ntp-15.1p2: 100%
[testingmerge] [181/219] Upgrading FreeBSD-nuageinit from 15.0 to 15.1...
[testingmerge] [181/219] Extracting FreeBSD-nuageinit-15.1: 100%
[testingmerge] [182/219] Upgrading FreeBSD-nvme-tools from 15.0 to 15.1...
[testingmerge] [182/219] Extracting FreeBSD-nvme-tools-15.1: 100%
[testingmerge] [183/219] Upgrading FreeBSD-openssl from 15.0p10 to 15.1...
[testingmerge] [183/219] Extracting FreeBSD-openssl-15.1: 100%
[testingmerge] [184/219] Upgrading FreeBSD-certctl from 15.0p10 to 15.1...
[testingmerge] [184/219] Extracting FreeBSD-certctl-15.1: 100%
[testingmerge] [185/219] Upgrading FreeBSD-caroot from 15.0 to 15.1...
[testingmerge] [185/219] Extracting FreeBSD-caroot-15.1: 100%
[testingmerge] [186/219] Upgrading FreeBSD-openssl-dev from 15.0p10 to 15.1...
[testingmerge] [186/219] Extracting FreeBSD-openssl-dev-15.1: 100%
[testingmerge] [187/219] Upgrading FreeBSD-openssl-lib from 15.0p10 to 15.1...
[testingmerge] [187/219] Extracting FreeBSD-openssl-lib-15.1: 100%
[testingmerge] [188/219] Upgrading FreeBSD-pf from 15.0p5 to 15.1...
[testingmerge] [188/219] Extracting FreeBSD-pf-15.1: 100%
[testingmerge] [189/219] Upgrading FreeBSD-pf-dev from 15.0 to 15.1...
[testingmerge] [189/219] Extracting FreeBSD-pf-dev-15.1: 100%
[testingmerge] [190/219] Upgrading FreeBSD-pmc from 15.0p11 to 15.1p2...
[testingmerge] [190/219] Extracting FreeBSD-pmc-15.1p2: 100%
[testingmerge] [191/219] Upgrading FreeBSD-pmc-dev from 15.0 to 15.1...
[testingmerge] [191/219] Extracting FreeBSD-pmc-dev-15.1: 100%
[testingmerge] [192/219] Upgrading FreeBSD-quotacheck from 15.0 to 15.1...
[testingmerge] [192/219] Extracting FreeBSD-quotacheck-15.1: 100%
[testingmerge] [193/219] Upgrading FreeBSD-rcmds from 15.0p9 to 15.1...
[testingmerge] [193/219] Extracting FreeBSD-rcmds-15.1: 100%
[testingmerge] [194/219] Upgrading FreeBSD-rdma from 15.0 to 15.1...
[testingmerge] [194/219] Extracting FreeBSD-rdma-15.1: 100%
[testingmerge] [195/219] Upgrading FreeBSD-rip from 15.0 to 15.1...
[testingmerge] [195/219] Extracting FreeBSD-rip-15.1: 100%
[testingmerge] [196/219] Upgrading FreeBSD-sendmail from 15.0p10 to 15.1...
[testingmerge] [196/219] Extracting FreeBSD-sendmail-15.1: 100%
[testingmerge] [197/219] Upgrading FreeBSD-smbutils from 15.0 to 15.1...
[testingmerge] [197/219] Extracting FreeBSD-smbutils-15.1: 100%
[testingmerge] [198/219] Upgrading FreeBSD-smbutils-dev from 15.0 to 15.1...
[testingmerge] [198/219] Extracting FreeBSD-smbutils-dev-15.1: 100%
[testingmerge] [199/219] Upgrading FreeBSD-sound from 15.0 to 15.1...
[testingmerge] [199/219] Extracting FreeBSD-sound-15.1: 100%
[testingmerge] [200/219] Upgrading FreeBSD-sound-dev from 15.0 to 15.1...
[testingmerge] [200/219] Extracting FreeBSD-sound-dev-15.1: 100%
[testingmerge] [201/219] Upgrading FreeBSD-ssh from 15.0p10 to 15.1...
[testingmerge] [201/219] Extracting FreeBSD-ssh-15.1: 100%
[testingmerge] [202/219] Upgrading FreeBSD-ssh-dev from 15.0p10 to 15.1...
[testingmerge] [202/219] Extracting FreeBSD-ssh-dev-15.1: 100%
[testingmerge] [203/219] Upgrading FreeBSD-syscons-data from 15.0 to 15.1...
[testingmerge] [203/219] Extracting FreeBSD-syscons-data-15.1: 100%
[testingmerge] [204/219] Upgrading FreeBSD-tcpd from 15.0 to 15.1...
[testingmerge] [204/219] Extracting FreeBSD-tcpd-15.1: 100%
[testingmerge] [205/219] Upgrading FreeBSD-tcpd-dev from 15.0 to 15.1...
[testingmerge] [205/219] Extracting FreeBSD-tcpd-dev-15.1: 100%
[testingmerge] [206/219] Upgrading FreeBSD-telnet from 15.0 to 15.1...
[testingmerge] [206/219] Extracting FreeBSD-telnet-15.1: 100%
[testingmerge] [207/219] Upgrading FreeBSD-tests from 15.0p12 to 15.1p2...
[testingmerge] [207/219] Extracting FreeBSD-tests-15.1p2: 100%
[testingmerge] [208/219] Upgrading FreeBSD-atf from 15.0 to 15.1...
[testingmerge] [208/219] Extracting FreeBSD-atf-15.1: 100%
[testingmerge] [209/219] Upgrading FreeBSD-atf-dev from 15.0 to 15.1...
[testingmerge] [209/219] Extracting FreeBSD-atf-dev-15.1: 100%
[testingmerge] [210/219] Upgrading FreeBSD-xz from 15.0 to 15.1...
[testingmerge] [210/219] Extracting FreeBSD-xz-15.1: 100%
[testingmerge] [211/219] Upgrading FreeBSD-xz-dev from 15.0 to 15.1...
[testingmerge] [211/219] Extracting FreeBSD-xz-dev-15.1: 100%
[testingmerge] [212/219] Installing FreeBSD-set-devel-15.1...
[testingmerge] [213/219] Upgrading FreeBSD-xz-lib from 15.0 to 15.1...
[testingmerge] [213/219] Extracting FreeBSD-xz-lib-15.1: 100%
[testingmerge] [214/219] Upgrading FreeBSD-set-minimal from 15.0 to 15.1...
[testingmerge] [215/219] Upgrading FreeBSD-yp from 15.0 to 15.1...
[testingmerge] [215/219] Extracting FreeBSD-yp-15.1: 100%
[testingmerge] [216/219] Installing FreeBSD-set-optional-15.1...
[testingmerge] [217/219] Installing FreeBSD-set-base-15.1...
[testingmerge] [218/219] Installing FreeBSD-tests-dbg-15.1p2...
[testingmerge] [218/219] Extracting FreeBSD-tests-dbg-15.1p2: 100%
[testingmerge] [219/219] Installing FreeBSD-set-tests-15.1...
==> Running trigger: mandoc.ucl
Generating apropos(1) database for /usr/share/man...
Generating apropos(1) database for /usr/share/openssl/man...
=====
Message from FreeBSD-local-unbound-15.1:

--
After upgrading local-unbound, the configuration file should be regenerated
by running "service local_unbound setup" before restarting the service.

Problem reproduced

After logging in again, I see:

dvl@testingmerge:~ $ tail -1 /var/log/messages
Aug 12 13:10:34 testingmerge pkg[9849]: FreeBSD-set-tests-15.1 installed

Not the expected result.

The file has changed:

dvl@testingmerge:~ $ ls -l /etc/pam.d/sshd 
-rw-r--r--  1 root wheel 564 Jun 12 09:42 /etc/pam.d/sshd
dvl@testingmerge:~ $ date
Wed Aug 12 13:12:22 UTC 2026
dvl@testingmerge:~ $ tail -1 /etc/pam.d/sshd
password	required	pam_unix.so		no_warn try_first_pass
dvl@testingmerge:~ $ 
Top

Microsoft Plugs Nearly 400 Security Holes

Post by Brian Krebs via Krebs on Security »

Microsoft today released updates to remedy at least 398 security vulnerabilities in its Windows operating systems and supported software, including one weakness that is already being actively exploited and two others that were publicly detailed prior to today.

Image: Shutterstock, Mallika Home Studio.

August’s overstuffed bundle of patch joy from Microsoft did not eclipse its recording breaking release of more than 570 security updates last month, but it is double June’s then-record batch of nearly 200 fixes. Microsoft has attributed the recent patch deluge to vulnerability discoveries aided by artificial intelligence, and experts roundly agree that Windows users should get used to the idea of Patch Tuesdays (the second Tuesday of each month) covering hundreds of newly discovered security flaws.

Fully 42 of the 398 flaws that Microsoft patched today earned Redmond’s most-dire “critical” rating, meaning they are severe enough that malware or malcontents could exploit them to gain remote control over a Windows computer with little to no help from the user.

The sole known “zero day” bug fixed by Microsoft this month is CVE-2026-68820, a privilege escalation weakness in a core Windows component called afd.sys, which the security firm Automox describes as “the driver behind Windows socket connections on effectively every endpoint.”

“This isn’t a front-door bug,” Automox’s Landon Miles wrote in a Patch Tuesday blog post. “It’s step two in a chain: an attacker phishes their way into a low-privilege foothold, then uses the driver flaw to take the box. The 7.0 score reflects the high attack complexity, because race conditions are fiddly. The exploit has to be thrown over and over until the timing lands. Someone is clearly landing it anyway.”

CVE-2026-62832 is another privilege escalation flaw that Microsoft has labeled likely to be exploited; this flaw, in the Windows User Profile Service, may be related to the recent “LegacyHive” public disclosure from the prolific bug hunter known as Nightmare Eclipse. The other publicly disclosed flaw is CVE-2026-72971, a low-impact local tampering vulnerability that Microsoft reckons is unlikely to be exploited.

Other major software makers are likewise increasing their patch volumes and cadence thanks to AI, including Adobe which last month moved to twice-monthly security bulletins published on the 2nd and 4th Tuesday of each month. Cisco, Google, Mozilla and Oracle also are shipping updates far more frequently and abundantly.

By all accounts, AI is quite good at finding security holes in software. But for now at least, patching the resulting bugpocalypse remains a heavily human-centric endeavor, and the jury is still out on whether AI technologies will turn out to be as good at fixing vulnerabilities as they are at finding and exploiting them. This is an important question when one considers that these same AI technologies also are suggesting fixes for the vulnerabilities they find.

Researchers at 1Password recently examined what happens when different large language models (LLMs) generate vulnerability patches for newly disclosed, complex vulnerabilities. They found the LLMs produced patches that failed to fix the flaw or added a new weakness in the process (or both) more than half the time.

Ed Skoudis, president of the SANS Technology Institute, said his team has seen excellent results using AI to generate patches, provided there are humans in the loop to test the suggested fixes and push for iterative improvements.

“AI is rapidly becoming astonishingly good at finding vulnerabilities, but this research shows that fixing them is a very different problem,” Skoudis wrote in a SANS newsletter today. “Don’t expect one-shot AI patching to work reliably. Instead, iterate, test, challenge, improve, and verify. AI can be an extraordinary patching partner, but today it still needs a skilled human at the keyboard.”

Tyler Reguly at Fortra says while reports of Microsoft patching hundreds of vulnerabilities in one go have prompted some organizations to try to patch faster, it’s important to bear in mind that only one of the almost 400 bugs addressed today is known to be actively exploited. Reguly suggested security leaders check in with their teams to see how they’re handling the increasing workloads, which often involve testing fixes before deploying them in production environments.

“If you’re a chief security officer talk to your teams about how they are shifting or modifying their workflows to better accommodate the patching shift that we’re seeing and support them across various organizational units by enabling the changes they want to see made,” Reguly said. “There’s no need to rush these updates, no matter what various vendors and organizations try to tell you. You need to make sure that you are rolling out safe updates that will not negatively impact your systems.”

Speaking of the humans behind the keyboards, don’t neglect to backup your system and/or data before applying this month’s monster patch load. The day after each month’s Patch Tuesday is sometimes derisively referred to as Reboot Wednesday, but it generally doesn’t hurt to wait a few days to apply these huge update bundles because it sometimes takes a couple of days for the occasional misbehaving patch to get ironed out properly by Microsoft.

For a clickable, per-patch breakdown by severity and urgency, check out this roundup from the SANS Internet Storm Center.

Top

Expat 2.8.3 released, fixes vulnerability CVE-2026-72522

Post by Sebastian Pipping via Hartwork Blog »

For readers new to Expat:

libexpat is a fast streaming XML parser. Alongside libxml2, Expat is one of the most widely used software libre XML parsers written in C, specifically C99. It is cross-platform and licensed under the MIT license.

Expat 2.8.3 was released yesterday. The key motivation for cutting a release and doing so now was getting…

  • the fix to vulnerability CVE-2026-72522 as well as
  • the fix to a regression in Expat 2.8.2

…out to users.

The vulnerability was reported by the Mozilla Security Team, and it relates to how Expat handles decoding of UTF-16. The vulnerability is technically an out-of-bounds read, and the symptom in practice is (easy and reliable) denial of service by means of an infinite loop. It should be noted that the CVSS vector by Mitre for CVE-2026-72522 in the National Vulnerability Database is (once again) misclassifying the attack vector as Local (L) when it should be Network (N): there are no requirements for local access with CVE-2026-72522.

The regression was that on 32bit platforms and on 64bit Windows, processing XML content of 2+ GiB size was rejected as "out of memory" by mistake. The issue was reported by Evgeny Kotkov a week ago in the context of Subversion's use of libexpat.

Thanks to everyone who contributed to this release of Expat!

For more details about this release, please check out the change log.

If you maintain Expat packaging, a bundled copy of Expat, or a pinned version of Expat, please update to version 2.8.3. Thank you!

Sebastian Pipping

Top

FreeBSD Storage for OpenShift with Democratic CSI

Post by Vermaden via 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗 »

Today quite different topic, using ZFS/NFS on FreeBSD as backend storage for containers/pods running on OpenShift platform.

Serving storage for OpenShift is not as simple as OpenShift will not just consume NFS or iSCSI volumes “just like that” … OpenShift requires a special CSI driver in between to make that even work.

By default one can use standard NFS CSI driver for OpenShift – it works – but has one important drawback. If You wand to create snapshot – then it just starts copying things 1:1 which makes it very slow and each snapshot takes the same place as the thing You want to snapshot.

With this Democratic CSI driver for NFS it uses SSH to connect to FreeBSD backend storage server and issues ZFS commands like zfs snapshot ... or others – so it creates native ultra fast ZFS snapshots without wasting space … and saving a lot of time.

My first association with CSI is of course CSI series like CSI: Miami … but the real name is Container Storage Interface of course :

While the Democratic CSI driver is suited mostly for Linux based systems like TrueNAS SCALE for example – its zfs-generic-nfs driver also works with FreeBSD – and this is what we will use today. The FreeBSD setup is very simple – its just NFSv4 only server and a dedicated NFS share for OpenShift along with dedicated ZFS dataset. One can also use any regular user with added ZFS permissions done via zfs allow command or a regular user with sudo(8) to lift up the permissions.

The FreeBSD/ZFS/NFS part was done my be – as I am not expert in the OpenShift domain – the OpenShift commands were done by luckyonesl and shared with his approval – thank You for help.

FreeBSD Server ZFS/NFS Setup

Latest FreeBSD 15.1-RELEASE was used for installation with Auto (ZFS) option. One can also use ready to download one of the FreeBSD VM-IMAGES that project also creates – in that case something ZFS based is needed. Just set the root password to something You will later use in the config. Using SSH keys instead of password is also possible. FreeBSD will use 10.0.0.9 IP address.

freebsd # echo "something+VERY-insecure-123" | pw usermod -n root -h 0

First create the ZFS dataset – as this is only for demonstration purposes I will just create zroot/openshift with /zroot/openshift as its mountpoint.

freebsd # zfs create -o mountpoint=/zroot/openshift zroot/openshift

As /etc/rc.conf is very basic – I will only focus on the NFS part here.

nfsv4_server_enable=YES
nfsv4_server_only=YES
mountd_enable=YES
nfs_server_enable=YES
nfs_server_flags="-t -n 64"
nfs_server_maxio=131072

The /etc/exports file for the NFS share. The hosts 10.0.0.10-13 are the nodes of OpenShift cluster.

V4: /            -sec=sys
/zroot/openshift -sec=sys -maproot=root 10.0.0.10 10.0.0.11 10.0.0.12 10.0.0.13

Now start the NFS server.

freebsd # service nfsd start

OpenShift Setup

Next are the needed OpenShift commands which were done by luckyonesl and shared with his approval as I am not that proficient in OpenShift.

One can use privateKey: instead of password: for more security – this is only for demonstration purposes.

Now the installation of Democratic CSI driver with helm(8) command.

openshift # cat /root/democratic-csi-install.yaml
image:
  repository: ghcr.io/democratic-csi/democratic-csi
  tag: v1.9.3
csiDriver:
  name: "org.democratic-csi.controller-zfs-generic"

controller:
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet

driver:
  config:
    logLevel: debug
    driver: zfs-generic-nfs
    sshConnection:
      host: 10.0.0.9
      port: 22
      username: root
      password: something+VERY-insecure-123
    zfs:
      cli:
        paths:
          zfs: /sbin/zfs
          zpool: /sbin/zpool
          sudo: /usr/local/bin/sudo     
      datasetParentName: "zroot/openshift"
      detachedSnapshots:
        enabled: false
      datasetPermissionsMode: "0777"
    nfs:
      shareStrategy: "setDatasetProperties"
      shareStrategySetDatasetProperties:
        properties:
          sharenfs: "on"
      shareHost: 10.0.0.9

storageClasses:
  - name: democratic-nfs
    defaultClass: false
    reclaimPolicy: Delete
    volumeBindingMode: Immediate
    allowVolumeExpansion: true

volumeSnapshotClasses:
  - name: democratic-nfs-snapshots
    parameters:
      detachedSnapshots:
        enabled: false


openshift # helm repo add democratic-csi https://democratic-csi.github.io/charts/

openshift # helm repo update

openshift # helm upgrade \
              --install democratic-csi democratic-csi/democratic-csi \
              -n democratic-csi \
              --create-namespace \
              -f /root/democratic-csi-install.yaml

Next check how the installation went.

openshift # oc get deployment,ds -n democratic-csi -o yaml | grep -iE 'hostNetwork'

openshift # oc get deployment,ds -n democratic-csi -o yaml | grep -iE 'hostNetwork|mountPropergation|privileged'

Sometimes additional polices/privileges are needed – so here are the commands for them.

openshift # oc adm policy add-scc-to-user privileged system:serviceaccount:democratic-csi:democratic-csi-controller-sa

openshift # oc adm policy add-scc-to-user privileged system:serviceaccount:democratic-csi:democratic-csi-node-ss

Tests on OpenShift

Now the Democratic CSI driver seems to be installed – lets use it as storage for OpenShift containers and create some snapshot(s). First the YAML files that will be used.

openshift # cat /root/csi-snapshot-test.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: csi-test
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: source-pvc
  namespace: csi-test
spec:
  storageClassName: democratic-nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: writer
  namespace: csi-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: writer
  template:
    metadata:
      labels:
        app: writer
    spec:
      containers:
      - name: writer
        image: busybox:1.36
        command:
        - sh
        - -c
        - |
          mkdir -p /data
          echo "Hello from FreeBSD snapshot test." > /data/test.txt
          date >> /data/test.txt
          echo "Sleeping..."
          sleep 3600
        volumeMounts:
        - name: storage
          mountPath: /data
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: source-pvc



openshift # cat /root/restore-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-pvc
  namespace: csi-test
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: democratic-nfs
  resources:
    requests:
      storage: 1Gi
  dataSource:
    name: source-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io



openshift # cat /root/restore-reader.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: restore-reader
  namespace: csi-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: restore-reader
  template:
    metadata:
      labels:
        app: restore-reader
    spec:
      containers:
      - name: shell
        image: alpine
        command:
        - /bin/sh
        - -c
        - sleep 3600
        volumeMounts:
        - name: data
          mountPath: /data
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: restored-pvc



openshift # cat /root/snapshot.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: source-snapshot
  namespace: csi-test
spec:
  volumeSnapshotClassName: democratic-nfs-snapshots
  source:
    persistentVolumeClaimName: source-pvc

… and now to messing with them.

openshift # oc apply -f /root/csi-snapshot-test.yaml

openshift # oc get pods -n csi-test

openshift # oc exec -n csi-test deploy/writer -- cat /data/test.txt

openshift # oc exec -n csi-test deploy/writer -- mount | grep /data

openshift # oc apply -f /root/snapshot.yaml

openshift # oc exec -n csi-test deploy/writer -- sh -c 'echo after-snapshot >> /data/test.txt'

openshift # oc get volumesnapshot -n csi-test -w

openshift # oc exec -n csi-test deploy/writer -- cat /data/test.txt 

openshift # oc scale deployment -n csi-test writer --replicas=0 

openshift # oc apply -f /root/restore-pvc.yaml

openshift # oc apply -f /root/restore-reader.yaml

openshift # oc exec -ti deployment/restore-reader -n csi-test  -- sh -c 'cat /data/test.txt'

openshift # oc exec -ti deployment/writer -n csi-test  -- sh -c 'cat /data/test.txt'

Sorry that I do not have output of the commands but it was some fast try to find out if and how it will work on FreeBSD …

Results on FreeBSD

Now this is how the FreeBSD system changed within these OpenShift operations. Just after NFS server startup and before any of these OpenShift commands were executed the ZFS datasets and snapshots looked like that:

freebsd # zfs list -t all
NAME                 USED  AVAIL  REFER  MOUNTPOINT
zroot               20.3G  68.6G    96K  /zroot
zroot/ROOT          3.03G  68.6G    96K  none
zroot/ROOT/default  3.03G  68.6G  3.03G  /
zroot/home            96K  68.6G    96K  /home
zroot/openshift     15.4G  68.6G   112K  /zroot/openshift
zroot/snaps           96K  68.6G    96K  /zroot/snaps
zroot/tmp            128K  68.6G   128K  /tmp
zroot/usr           1.88G  68.6G    96K  /usr
zroot/usr/ports       96K  68.6G    96K  /usr/ports
zroot/usr/src       1.88G  68.6G  1.88G  /usr/src
zroot/var           1.41M  68.6G    96K  /var
zroot/var/audit       96K  68.6G    96K  /var/audit
zroot/var/crash      100K  68.6G   100K  /var/crash
zroot/var/log        880K  68.6G   880K  /var/log
zroot/var/mail       172K  68.6G   172K  /var/mail
zroot/var/tmp         96K  68.6G    96K  /var/tmp

Next – as OpenShift requested the storage new ZFS datasets have been created and also requested snapshots.

freebsd # zfs list -t all
NAME                                                                                                     USED  AVAIL  REFER  MOUNTPOINT
zroot                                                                                                   20.3G  68.6G    96K  /zroot
zroot/ROOT                                                                                              3.03G  68.6G    96K  none
zroot/ROOT/default                                                                                      3.03G  68.6G  3.03G  /
zroot/home                                                                                                96K  68.6G    96K  /home
zroot/openshift                                                                                         15.4G  68.6G   112K  /zroot/openshift
zroot/openshift/pvc-5455ae63-a585-4865-a875-50f53e936a87                                                  56K  68.6G   100K  /zroot/openshift/pvc-5455ae63-a585-4865-a875-50f53e936a87
zroot/openshift/pvc-de5515f3-8b0e-42ed-ba51-8ea7a347c815                                                15.4G  68.6G  15.4G  /zroot/openshift/pvc-de5515f3-8b0e-42ed-ba51-8ea7a347c815
zroot/openshift/pvc-de5515f3-8b0e-42ed-ba51-8ea7a347c815@snapshot-c96db74d-7ec2-420b-8fab-53a01119d4b7    68K      -   100K  -
zroot/openshift/pvc-de5515f3-8b0e-42ed-ba51-8ea7a347c815@snapshot-4d5582dd-7e34-411f-924c-163487ba6160    68K      -  9.77G  -
zroot/openshift/pvc-de5515f3-8b0e-42ed-ba51-8ea7a347c815@snapshot-1dc2ba05-668d-44dc-bd29-063600a85eaa    60K      -  25.2G  -
zroot/snaps                                                                                               96K  68.6G    96K  /zroot/snaps
zroot/tmp                                                                                                128K  68.6G   128K  /tmp
zroot/usr                                                                                               1.88G  68.6G    96K  /usr
zroot/usr/ports                                                                                           96K  68.6G    96K  /usr/ports
zroot/usr/src                                                                                           1.88G  68.6G  1.88G  /usr/src
zroot/var                                                                                               1.41M  68.6G    96K  /var
zroot/var/audit                                                                                           96K  68.6G    96K  /var/audit
zroot/var/crash                                                                                          100K  68.6G   100K  /var/crash
zroot/var/log                                                                                            880K  68.6G   880K  /var/log
zroot/var/mail                                                                                           172K  68.6G   172K  /var/mail
zroot/var/tmp                                                                                             96K  68.6G    96K  /var/tmp

freebsd # find /zroot/openshift
/zroot/openshift
/zroot/openshift/pvc-de5515f3-8b0e-42ed-ba51-8ea7a347c815
/zroot/openshift/pvc-de5515f3-8b0e-42ed-ba51-8ea7a347c815/test.txt
/zroot/openshift-5455ae63-a585-4865-a875-50f53e936a87
/zroot/openshift/pvc-5455ae63-a585-4865-a875-50f53e936a87/test.txt

Not sure what else I should add here – as the topic is still fresh I will update and maybe add more things when they come.

EOF
Top

Valuable News – 2026/08/10

Post by Vermaden via 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗 »

The Valuable News weekly series is dedicated to provide summary about news, articles and other interesting stuff mostly but not always related to the UNIX/BSD/Linux systems. Whenever I stumble upon something worth mentioning on the Internet I just put it here.

Today the amount information that we get using various information streams is at massive overload. Thus one needs to focus only on what is important without the need to grep(1) the Internet everyday. Hence the idea of providing such information ‘bulk’ as I already do that grep(1).

The Usual Suspects section at the end is permanent and have links to other sites with interesting UNIX/BSD/Linux news.

Past releases are available at the dedicated NEWS page.

UNIX

FreeBSD 14.5-BETA1 Now Available.
https://lists.freebsd.org/archives/freebsd-stable/2026-August/004267.html

Ansible Modules for Managing Sylve (Bhyve and Jails) on FreeBSD.
https://git.gyptazy.com/gyptazy/sylve-ansible

FreeBSD Git Weekly: 2026-07-27 to 2026-08-02.
https://freebsd-git-weekly.tarsnap.net/2026-07-27.html

Call for Testing: OpenBSD vmm(4)/vmd(8) Fd-ification.
https://undeadly.org/cgi?action=article;sid=20260804054218

Run Your Own Mail Server with OpenBSD and OpenSMTPD.
https://bsd-audit.com/self-hosting/running-your-own-mailserver/

Show Memory Information on OpenBSD.
https://bsd-audit.com/openbsd/memory-information-on-openbsd/

FFmpeg 9.0 Released with More Vulkan Acceleration and Animated WebP Support.
https://phoronix.com/news/FFmpeg-9.0-Released

Rust Coreutils 0.10 Released with More Security Hardening and Increased GNU Compatibility.
https://phoronix.com/news/Rust-Coreutils-0.10

FreeBSD /etc/pam.d/sshd Was Updated/Overwritten.
https://dan.langille.org/2026/08/07/freebsd-etc-pam-d-sshd-was-updated-overwritten-no-merge-attempt/

TIL zfs-userspace(8) Command.
https://antranigv.am/posts/2026/08/til-zfs-userspace/

FreeBSD 14.5-BETA1 Released with Various Backports and Security Fixes.
https://phoronix.com/news/FreeBSD-14.5-Beta-1

GSoC 2026: Port Enlightenment Desktop Environment to NetBSD.
https://blog.netbsd.org/tnf/entry/gsoc2026_enlightenment

Pushing BSD make(1) to Places It Was Not Designed for.
https://github.com/b-aaz/bmake-extravaganza/tree/master

FreeBSD Storage for OpenShift with Democratic CSI.
https://vermaden.wordpress.com/2026/08/09/freebsd-openshift-democratic-csi/

SonicDE for Slackware Linux.
https://sonicde-slackware.github.io/

UNIX/Audio/Video

NetBSD 11.0 Install Tutorial.
https://youtube.com/watch?v=uhUvajnO9RU

How to Install NetBSD 11.0 (2027 Edition).
https://youtube.com/watch?v=lzPKWYSk_qA

BSD Now 675: Going GPL Free.
https://www.bsdnow.tv/675

Hardware

This Medieval Astrolabe Turns 1000 Years Old.
https://www.medievalists.net/2026/08/this-medieval-astrolabe-turns-1000-years-old/

Other

Lazy Reading for 2026/08/09.
https://dragonflydigest.com/2026/08/09/lazy-reading-for-2026-08-09/

Quake 4: The Awakening Release.
https://github.com/jmarshall23/Quake_4_Alpha

Windows XP 2002 for Itanium: Unbridled Rage.
https://virtuallyfun.com/2026/08/03/windows-xp-2002-for-the-itanium-unbridled-rage/

Usual Suspects

BSD Weekly.
https://bsdweekly.com/

DiscoverBSD.
https://discoverbsd.com/

BSDSec.
https://bsdsec.net/

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

BSDTV.
https://bsky.app/profile/bsdtv.bsky.social

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

BSDJedi.
https://youtube.com/@BSDJedi/videos

RoboNuggie.
https://youtube.com/@RoboNuggie/videos

GaryHTech.
https://youtube.com/@GaryHTech/videos

Sheridan Computers.
https://youtube.com/@sheridans/videos

82MHz.
https://82mhz.net/

EOF
Top

FreeBSD 14.5-BETA1 Available

Post by FreeBSD Newsflash via FreeBSD News Flash »

The first BETA build for the FreeBSD 14.5 release cycle is now available. ISO images for the amd64, i386, armv7, aarch64, powerpc, powerpcspe, powerpc64, powerpc64le, and riscv64 architectures are FreeBSD mirror sites.
Top

Updating FreeBSD 15.0 to FreeBSD 15.1 (via pkgbase)

Post by Dan Langille via Dan Langille's Other Diary »

NOTE: I suspect some configuration file changes happened silently. See FreeBSD – /etc/pam.d/sshd was updated/overwritten – no merge attempt

I decided that Thursday morning at 8:27 AM was the right time to start my first update from FreeBSD 15.0 to 15.1 – all my hosts are now on pkgbase. I used the pgkbasify script. Now it’s time to update again.

In this post:

In the following sections, I am showing the steps I carried out. The section names here have the same names as the instructions.

Is it really pkgbase?

As seen under Introduction, I will be following the Upgrading with Base System Packages instructions:

[12:31 nagios04 dvl ~] % pkg which /usr/bin/uname
/usr/bin/uname was installed by package FreeBSD-runtime-15.0p11

Snapshot the Current Installation

I create a new boot environment; this is the fallback position.

[12:33 nagios04 root ~] # bectl create -r pre-15.1
[12:33 nagios04 root ~] # 

Upgrade the Installed System

[12:33 nagios04 root ~] # pkg upgrade -r FreeBSD-base
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
FreeBSD-base is up to date.
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.

Upgrade the Base System

The main thing to take note of in the paste below, this removal. Everything else seems OK. Turns out, it was of no consequence

Installed packages to be REMOVED:
	FreeBSD-lldb-dev: 15.0

The full output is in this gist.

[12:34 nagios04 root ~] # pkg -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000 upgrade -r FreeBSD-base
Updating FreeBSD-base repository catalogue...
pkg: Repository FreeBSD-base has a wrong packagesite, need to re-create database
Fetching meta.conf: 100%     179 B   0.2 kB/s    00:01    
Fetching data: 100%    82 KiB  84.0 kB/s    00:01    
Processing entries: 100%
FreeBSD-base repository update completed. 509 packages processed.
FreeBSD-base is up to date.
Checking for upgrades (486 candidates): 100%
Processing candidates (486 candidates): 100%
The following 499 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	FreeBSD-pam: 15.1 [FreeBSD-base]
	FreeBSD-pam-dbg: 15.1 [FreeBSD-base]
	FreeBSD-pam-dbg-lib32: 15.1 [FreeBSD-base]
	FreeBSD-pam-dev: 15.1 [FreeBSD-base]
	FreeBSD-pam-dev-lib32: 15.1 [FreeBSD-base]
	FreeBSD-pam-lib: 15.1 [FreeBSD-base]
	FreeBSD-pam-lib32: 15.1 [FreeBSD-base]
	FreeBSD-zstd: 15.1 [FreeBSD-base]
	FreeBSD-zstd-dbg: 15.1 [FreeBSD-base]
	FreeBSD-zstd-dbg-lib32: 15.1 [FreeBSD-base]
	FreeBSD-zstd-dev: 15.1 [FreeBSD-base]
	FreeBSD-zstd-dev-lib32: 15.1 [FreeBSD-base]
	FreeBSD-zstd-lib: 15.1 [FreeBSD-base]
	FreeBSD-zstd-lib32: 15.1 [FreeBSD-base]

Installed packages to be UPGRADED:
	FreeBSD-acct: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-acct-dbg: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-acpi: 15.0 -> 15.1 [FreeBSD-base]
...
	FreeBSD-zlib-lib32: 15.0 -> 15.1 [FreeBSD-base]
	FreeBSD-zoneinfo: 15.0p7 -> 15.1 [FreeBSD-base]

Number of packages to be installed: 14
Number of packages to be upgraded: 485

The process will require 12 MiB more space.
672 MiB to be downloaded.

Proceed with this action? [y/N]: y
[  1/499] Fetching FreeBSD-libmilter-dev-15.1: 100%    86 KiB  87.8 kB/s    00:01    
...
[499/499] Fetching FreeBSD-ctf-dev-15.1: 100%   138 KiB 141.1 kB/s    00:01    
Checking integrity... done (24 conflicting)
  - FreeBSD-sound-15.1 [FreeBSD-base] conflicts with FreeBSD-rc-15.0 [installed] on /etc/rc.d/mixer
  - FreeBSD-atf-15.1 [FreeBSD-base] conflicts with FreeBSD-tests-15.0p11 [installed] on /usr/share/atf/libatf-sh.subr
  - FreeBSD-pam-dbg-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dbg-lib32-15.0p11 [installed] on /usr/lib/debug/usr/lib32/libpam.so.6.debug
  - FreeBSD-pam-dbg-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-dbg-lib32-15.0p11 [installed] on /usr/lib/debug/usr/lib32/pam_chroot.so.6.debug
  - FreeBSD-zstd-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-15.0p11 [installed] on /usr/bin/unzstd
  - FreeBSD-pam-dbg-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dbg-15.0p11 [installed] on /usr/lib/debug/usr/lib/libpam.so.6.debug
  - FreeBSD-pam-dbg-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-dbg-15.0p11 [installed] on /usr/lib/debug/usr/lib/pam_chroot.so.6.debug
  - FreeBSD-clang-15.1p1 [FreeBSD-base] conflicts with FreeBSD-lldb-15.0p11 [installed] on /usr/lib/libprivatelldb.so.19
  - FreeBSD-pam-lib-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p11 [installed] on /usr/lib/libpam.so.6
  - FreeBSD-zstd-dev-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-lib32-15.0p11 [installed] on /usr/lib32/libprivatezstd.a
  - FreeBSD-pam-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-lib32-15.0p11 [installed] on /usr/lib32/libpam.so.6
  - FreeBSD-pam-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-lib32-15.0p11 [installed] on /usr/lib32/pam_chroot.so
  - FreeBSD-zstd-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-lib32-15.0p11 [installed] on /usr/lib32/libprivatezstd.so.5
  - FreeBSD-zstd-lib-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p11 [installed] on /usr/lib/libprivatezstd.so.5
  - FreeBSD-pam-dev-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-lib32-15.0p11 [installed] on /usr/lib32/libpam.a
  - FreeBSD-zstd-dbg-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dbg-lib32-15.0p11 [installed] on /usr/lib/debug/usr/lib32/libprivatezstd.so.5.debug
  - FreeBSD-clang-dbg-15.1p1 [FreeBSD-base] conflicts with FreeBSD-lldb-dbg-15.0p11 [installed] on /usr/lib/debug/usr/lib/libprivatelldb.so.19.debug
  - FreeBSD-clang-dev-15.1p1 [FreeBSD-base] conflicts with FreeBSD-lldb-dev-15.0 [installed] on /usr/lib/libprivatelldb.so
  - FreeBSD-zstd-dev-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-15.0p11 [installed] on /usr/include/private/zstd/zstd.h
  - FreeBSD-pam-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p11 [installed] on /etc/pam.d/README
  - FreeBSD-pam-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-15.0p11 [installed] on /usr/lib/pam_chroot.so
  - FreeBSD-zstd-dbg-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-dbg-15.0p11 [installed] on /usr/lib/debug/usr/bin/zstd.debug
  - FreeBSD-zstd-dbg-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dbg-15.0p11 [installed] on /usr/lib/debug/usr/lib/libprivatezstd.so.5.debug
  - FreeBSD-pam-dev-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-15.0p11 [installed] on /usr/include/security/openpam.h
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 500 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	FreeBSD-pam: 15.1 [FreeBSD-base]
	FreeBSD-pam-dbg: 15.1 [FreeBSD-base]
	FreeBSD-pam-dbg-lib32: 15.1 [FreeBSD-base]
	FreeBSD-pam-dev: 15.1 [FreeBSD-base]
	FreeBSD-pam-dev-lib32: 15.1 [FreeBSD-base]
	FreeBSD-pam-lib: 15.1 [FreeBSD-base]
	FreeBSD-pam-lib32: 15.1 [FreeBSD-base]
	FreeBSD-zstd: 15.1 [FreeBSD-base]
	FreeBSD-zstd-dbg: 15.1 [FreeBSD-base]
	FreeBSD-zstd-dbg-lib32: 15.1 [FreeBSD-base]
	FreeBSD-zstd-dev: 15.1 [FreeBSD-base]
	FreeBSD-zstd-dev-lib32: 15.1 [FreeBSD-base]
	FreeBSD-zstd-lib: 15.1 [FreeBSD-base]
	FreeBSD-zstd-lib32: 15.1 [FreeBSD-base]

Installed packages to be UPGRADED:
	FreeBSD-acct: 15.0 -> 15.1 [FreeBSD-base]
...
	FreeBSD-zoneinfo: 15.0p7 -> 15.1 [FreeBSD-base]

Installed packages to be REMOVED:
	FreeBSD-lldb-dev: 15.0

Number of packages to be removed: 1
Number of packages to be installed: 14
Number of packages to be upgraded: 485

The process will require 12 MiB more space.

Proceed with this action? [y/N]: y
Checking integrity... done (0 conflicting)
[  1/507] Upgrading FreeBSD-bootloader from 15.0 to 15.1...
[  1/507] Extracting FreeBSD-bootloader-15.1: 100%
...
[506/507] Installing FreeBSD-set-optional-dbg-15.1...
[507/507] Installing FreeBSD-set-base-dbg-15.1...
==> Running trigger: mandoc.ucl
Generating apropos(1) database for /usr/share/man...
Generating apropos(1) database for /usr/share/openssl/man...
=====
Message from FreeBSD-local-unbound-15.1:

--
After upgrading local-unbound, the configuration file should be regenerated
by running "service local_unbound setup" before restarting the service.

Upgrade Third-party Kernel Modules

[12:43 nagios04 root ~] # pkg upgrade -r FreeBSD-ports-kmods
Updating FreeBSD-ports-kmods repository catalogue...
pkg: Repository FreeBSD-ports-kmods has a wrong packagesite, need to re-create database
Fetching meta.conf: 100%     179 B   0.2 kB/s    00:01    
Fetching data: 100%    35 KiB  35.6 kB/s    00:01    
Processing entries: 100%
FreeBSD-ports-kmods repository update completed. 239 packages processed.
FreeBSD-ports-kmods is up to date.
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
[12:44 nagios04 root ~] # 

Check for Failed Configuration Updates

[12:44 nagios04 root ~] # find /etc /usr/local/etc -name '*.pkgnew' -ls
[12:46 nagios04 root ~] # 
[12:46 nagios04 root ~] # sysctl machdep.bootmethod
machdep.bootmethod: UEFI

Identifying the ESP

[12:46 nagios04 root ~] # efibootmgr -v
Boot to FW : false
BootCurrent: 0001
Timeout    : 0 seconds
BootOrder  : 0001, 0000
+Boot0001* EFI SCSI Device AcpiEx(@@@0000,@@@0000,0x0,VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,d96361baa104294db60572e2ffb1dc7f1a78b3f8821e1848a1c363d806ec15bb)/Scsi(0x0,0x0)
 Boot0000* EFI Network AcpiEx(@@@0000,@@@0000,0x0,VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,635161f83edfc546913ff2d2f965ed0ed63a0d000bbd0d003ad6bd0b000d3ad6)/MAC(000000000000,0x0)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)


Unreferenced Variables:
 Boot0002* EFI SCSI Device AcpiEx(@@@0000,@@@0000,0x0,VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,d96361baa104294db60572e2ffb1dc7f1a78b3f8821e1848a1c363d806ec15bb)/Scsi(0x0,0x1)
[12:49 nagios04 root ~] # 

Eh? That doesn’t resemble the documented output at all. The drive device is not mentioned.

I know I have this:

[12:49 nagios04 root ~] # gpart show
=>       40  134217648  da0  GPT  (64G)
         40       2008       - free -  (1004K)
       2048        348    1  freebsd-boot  (174K)
       2396      66584    2  efi  (33M)
      68980   62914560    3  freebsd-zfs  (30G)
   62983540   71234148       - free -  (34G)

=>      40  33554352  da1  GPT  (16G)
        40  29360048    1  freebsd-ufs  (14G)
  29360088   4194304    2  freebsd-swap  (2.0G)

[12:50 nagios04 root ~] # zpool list

As such, I’d expect to see da0p2 in the output above.

I sought advice via IRC. The consensus was: proceed using da0p2.

Mounting the ESP

[13:28 nagios04 root ~] # mount_msdosfs /dev/da0p2 /boot/efi
mount_msdosfs: /dev/da0p2: Operation not permitted

[13:28 nagios04 root ~] # mount | grep /boot/efi 
/dev/gpt/efiboot0 on /boot/efi (msdosfs, local)

Eh? What’s that? Oh, it’s da0p2 by another name:

[13:28 nagios04 root ~] # gpart show -l
=>       40  134217648  da0  GPT  (64G)
         40       2008       - free -  (1004K)
       2048        348    1  bootfs  (174K)
       2396      66584    2  efiboot0  (33M)
      68980   62914560    3  rootfs  (30G)
   62983540   71234148       - free -  (34G)

=>      40  33554352  da1  GPT  (16G)
        40  29360048    1  (null)  (14G)
  29360088   4194304    2  (null)  (2.0G)

[13:29 nagios04 root ~] # 

See efiboot0 mentioned there… same thing as da0p2

Install the Boot Loader

The instructions say (for me, on amd64) to do this:

cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi

However, the /boot/efi/efi/freebsd directory does not exist on my host.

Consultations indicated that this system does not have an efi boot entry and is relying on bootx64.efi

… it is now Friday morning, and I have resumed my quest. In the meantime, the host has been performing as expected.

Back to my directories.

Is this a situation to be fixed?

Answer was: no particular need to fix it if the system boots fine.

Onward I go!

[16:07 nagios04 root ~] # cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi
[16:10 nagios04 root ~] # 

NOTE: that is an MSDOS file system:

[16:13 nagios04 root ~] # mount | grep /boot/efi
/dev/gpt/efiboot0 on /boot/efi (msdosfs, local)

Finish

Before you reboot, I didn’t do the following on this host, but I did on the next host. I set the BE to boot one time (-t). In case there was a problem, the next boot would be back on FreeBSD 15.0. This is how I did that:

[16:42 r730-03 root ~] # bectl list 
BE                                Active Mountpoint Space Created
15.0-RELEASE-p9_2026-06-10_111727 -      -          468M  2026-06-10 11:17
default                           NR     /          15.1G 2023-08-10 21:51
pre-15.1                          -      -          948K  2026-07-17 16:37
pre-pkgbasify_2026-06-30_152431   -      -          397M  2026-06-30 15:24

[16:42 r730-03 root ~] # bectl activate pre-15.1
Successfully activated boot environment pre-15.1
[16:42 r730-03 root ~] # bectl activate -t default
Successfully activated boot environment default for next boot
[16:42 r730-03 root ~] # sudo shutdown -r now
Shutdown NOW!
shutdown: [pid 37935]

....

[12:46 pro05 dvl ~] % r730-03
Last login: Fri Jul 17 16:37:25 2026 from pro05.startpoint.vpn.unixathome.org
[16:46 r730-03 dvl ~] % uptime
 4:46PM  up 42 secs, 1 user, load averages: 0.35, 0.09, 0.03
[16:46 r730-03 dvl ~] % freebsd-version -ukr
15.1-RELEASE-p1
15.1-RELEASE-p1
15.1-RELEASE-p1


[16:46 r730-03 dvl ~] % uname -a
FreeBSD r730-03.int.unixathome.org 15.1-RELEASE-p1 FreeBSD 15.1-RELEASE-p1 releng/15.1-n283582-0f691888dc56 GENERIC amd64
[16:46 r730-03 dvl ~] % bectl list
BE                                Active Mountpoint Space Created
15.0-RELEASE-p9_2026-06-10_111727 -      -          468M  2026-06-10 11:17
default                           N      /          1.49G 2023-08-10 21:51
pre-15.1                          R      -          13.6G 2026-07-17 16:37
pre-pkgbasify_2026-06-30_152431   -      -          397M  2026-06-30 15:24
[16:46 r730-03 dvl ~] % sudo bectl activate default
Successfully activated boot environment default
[16:47 r730-03 dvl ~] % bectl list                 
BE                                Active Mountpoint Space Created
15.0-RELEASE-p9_2026-06-10_111727 -      -          468M  2026-06-10 11:17
default                           NR     /          15.1G 2023-08-10 21:51
pre-15.1                          -      -          952K  2026-07-17 16:37
pre-pkgbasify_2026-06-30_152431   -      -          397M  2026-06-30 15:24
[16:47 r730-03 dvl ~] % 

I’m happy with the boot, so I made default the next boot for the BE.

This is what I did with this host:

[16:14 nagios04 root ~] # shutdown -r now
Shutdown NOW!
shutdown: [pid 7690]
[16:14 nagios04 root ~] #                                                                                
*** FINAL System shutdown message from dvl@nagios04.unixathome.org ***       

System going down IMMEDIATELY                                                  

                                                                               
                                                                               
*** FINAL System shutdown message from dvl@nagios04.unixathome.org ***       

System going down IMMEDIATELY                                                  

                                                                               

System shutdown time has arrived
Connection to nagios04.unixathome.org closed by remote host.
Connection to nagios04.unixathome.org closed.
[12:15 pro05 dvl ~] % 

Success

Welcome to my first FreeBSD 15.1 host:

[12:15 pro05 dvl ~] % nagios04 
Last login: Fri Jul 17 15:55:22 2026 from tallboy.unixathome.org
[16:15 nagios04 dvl ~] % uptime
 4:15PM  up 37 secs, 1 user, load averages: 0.30, 0.08, 0.03
[16:15 nagios04 dvl ~] % freebsd-version -urk
15.1-RELEASE-p1
15.1-RELEASE-p1
15.1-RELEASE-p1
[16:15 nagios04 dvl ~] % 

Things which go wrong

Sometimes, there is an Authentication error. Perhaps multiple times during one update. For this host, it was 4 times.

In which case, just try again:

[17:21 zuul root ~] # pkg -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000 upgrade -r FreeBSD-base
Updating FreeBSD-base repository catalogue...
pkg: Repository FreeBSD-base has a wrong packagesite, need to re-create database
Fetching meta.conf: 100%     179 B   0.2 kB/s    00:01    
Fetching data: 100%    82 KiB  84.0 kB/s    00:01    

...

[123/340] Fetching FreeBSD-clang-15.1p1: 100%    38 MiB   6.6 MB/s    00:06    
[124/340] Fetching FreeBSD-cron-15.1: 100%    39 KiB  40.1 kB/s    00:01    
pkg: https://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/base_release_1/Hashed/FreeBSD-utilities-dbg-15.1p1~2f499f2b0b.pkg: Authentication error
[17:22 zuul root ~] # pkg -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000 upgrade -r FreeBSD-base
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
FreeBSD-base is up to date.
Checking for upgrades (333 candidates): 100%
Processing candidates (333 candidates): 100%
The following 340 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	FreeBSD-pam: 15.1 [FreeBSD-base]

...
	FreeBSD-zoneinfo: 15.0p7 -> 15.1 [FreeBSD-base]

Number of packages to be installed: 8
Number of packages to be upgraded: 332

The operation will free 1 MiB.
359 MiB to be downloaded.

Proceed with this action? [y/N]: y
[  1/216] Fetching FreeBSD-utilities-dbg-15.1p1: 100%    13 MiB   4.7 MB/s    00:03    
[  2/216] Fetching FreeBSD-xz-dbg-15.1: 100%   298 KiB 305.5 kB/s    00:01    
...
[ 48/216] Fetching FreeBSD-hast-15.1: 100%   102 KiB 104.8 kB/s    00:01    
pkg: https://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/base_release_1/Hashed/FreeBSD-bluetooth-15.1~e5694024a5.pkg: Authentication error

Repeat.. etc. Eventually, you’ll get them all downloaded.

For more bootloader fun, see https://forums.freebsd.org/threads/bootloader-issue-on-freebsd-15-0-15-1-upgrade.103300/

Top

Updating a FreeBSD 15.0 jail to FreeBSD 15.1 (via pkgbase)

Post by Dan Langille via Dan Langille's Other Diary »

NOTE: I suspect some configuration file changes happened silently. See FreeBSD – /etc/pam.d/sshd was updated/overwritten – no merge attempt

On Friday, I finished upgrading all my FreeBSD hosts from FreeBSD 15 to FreeBSD 15.1 (the first host I did is in this blog post ).

Before that, I had run pkgbasify on each of those hosts.

I also ran pkgbasify in a jail, but I learned that I can run it from the host, using the -j parameter.

Today, I’m going to update that jail using pkgbase, from outside the jail.

In this post:

I am going to follow the above instructions, duplicating their section names here, for easier cross reference.

I will be running the commands on the host and using the -j parameter.

My commands will use the MYJAIL variable to make your copy/paste easier. Just adjust the export statement to reference your jail.

Introduction

[22:31 r730-03 dvl ~] % export MYJAIL=empty
[22:32 r730-03 dvl ~] % sudo pkg -j $MYJAIL which /usr/bin/uname
/usr/bin/uname was installed by package FreeBSD-runtime-15.0p11

Great. The jail has been pkgbasified. :)

Upgrading with Base System Packages

Snapshot the Current Installation

Well, since it’s a jail:

[22:35 r730-03 dvl ~] % zfs list | grep empty
data01/jails/empty                            41.4G  7.49T  37.2G  /jails/empty
[22:36 r730-03 dvl ~] % sudo zfs snapshot data01/jails/empty@pre-15.1
[22:36 r730-03 dvl ~] % 

Sorry, no variable used there.

Upgrade the Installed System

[22:36 r730-03 dvl ~] % sudo pkg -j $MYJAIL upgrade -r FreeBSD-base
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
FreeBSD-base is up to date.
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.

Upgrade the Base System

Don’t issue this command. See below.

[22:38 r730-03 dvl ~] % sudo pkg -j $MYJAIL -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000 upgrade -r FreeBSD-base
Updating FreeBSD-base repository catalogue...
pkg: Repository FreeBSD-base has a wrong packagesite, need to re-create database
[empty.int.unixathome.org] Fetching meta.conf: 100%     179 B   0.2 kB/s    00:01    
[empty.int.unixathome.org] Fetching data: 100%    82 KiB  84.0 kB/s    00:01    
Processing entries: 100%
FreeBSD-base repository update completed. 509 packages processed.
FreeBSD-base is up to date.
Checking for upgrades (312 candidates): 100%
Processing candidates (312 candidates): 100%
The following 321 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        FreeBSD-pam: 15.1 [FreeBSD-base]
        FreeBSD-pam-dev: 15.1 [FreeBSD-base]
        FreeBSD-pam-dev-lib32: 15.1 [FreeBSD-base]
...
        FreeBSD-zoneinfo: 15.0p7 -> 15.1 [FreeBSD-base]

Installed packages to be REMOVED:
        FreeBSD-lldb-dev: 15.0

Number of packages to be removed: 1
Number of packages to be installed: 10
Number of packages to be upgraded: 311

The process will require 2 MiB more space.

Proceed with this action? [y/N]: y
Checking integrity... done (0 conflicting)
pkg: Package FreeBSD-cron has files with flags that cannot be managed in this jail. Set allow.chflags in the jail configuration.

AHH, I have to changeallow.chflags. If you review Running pkgbasify on a FreeBSD 15.0 jail, you’ll see I had to add this to the jail config:

    # added for pkgbasify
    allow.chflags;
    securelevel = -1;

I’ll do that, restart the jail, and try the same command again.

The full output is at: https://gist.github.com/dlangille/de625f5c50a66542567e8862c30da375

[22:41 r730-03 dvl ~] % sudo pkg -j $MYJAIL -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000 upgrade -r FreeBSD-base
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
FreeBSD-base is up to date.
Checking for upgrades (312 candidates): 100%
Processing candidates (312 candidates): 100%
Checking integrity...
  - FreeBSD-zstd-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-15.0p11 [installed] on /usr/bin/unzstd
  - FreeBSD-clang-15.1p1 [FreeBSD-base] conflicts with FreeBSD-lldb-15.0p11 [installed] on /usr/lib/libprivatelldb.so.19
  - FreeBSD-pam-lib-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p11 [installed] on /usr/lib/libpam.so.6
  - FreeBSD-zstd-dev-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-lib32-15.0p11 [installed] on /usr/lib32/libprivatezstd.a
  - FreeBSD-pam-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-lib32-15.0p11 [installed] on /usr/lib32/libpam.so.6
  - FreeBSD-pam-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-lib32-15.0p11 [installed] on /usr/lib32/pam_chroot.so
  - FreeBSD-zstd-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-lib32-15.0p11 [installed] on /usr/lib32/libprivatezstd.so.5
  - FreeBSD-zstd-lib-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p11 [installed] on /usr/lib/libprivatezstd.so.5
  - FreeBSD-pam-dev-lib32-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-lib32-15.0p11 [installed] on /usr/lib32/libpam.a
  - FreeBSD-clang-dev-15.1p1 [FreeBSD-base] conflicts with FreeBSD-lldb-dev-15.0 [installed] on /usr/lib/libprivatelldb.so
  - FreeBSD-zstd-dev-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-15.0p11 [installed] on /usr/include/private/zstd/zstd.h
  - FreeBSD-pam-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p11 [installed] on /etc/pam.d/README
  - FreeBSD-pam-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-15.0p11 [installed] on /usr/lib/pam_chroot.so
  - FreeBSD-pam-dev-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-15.0p11 [installed] on /usr/include/security/openpam.h
Checking integrity... done (0 conflicting)
The following 322 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        FreeBSD-pam: 15.1 [FreeBSD-base]
        FreeBSD-pam-dev: 15.1 [FreeBSD-base]
        FreeBSD-pam-dev-lib32: 15.1 [FreeBSD-base]
        FreeBSD-pam-lib: 15.1 [FreeBSD-base]
        FreeBSD-pam-lib32: 15.1 [FreeBSD-base]
        FreeBSD-zstd: 15.1 [FreeBSD-base]
        FreeBSD-zstd-dev: 15.1 [FreeBSD-base]
        FreeBSD-zstd-dev-lib32: 15.1 [FreeBSD-base]
        FreeBSD-zstd-lib: 15.1 [FreeBSD-base]
        FreeBSD-zstd-lib32: 15.1 [FreeBSD-base]

Installed packages to be UPGRADED:
        FreeBSD-acct: 15.0 -> 15.1 [FreeBSD-base]

...

        FreeBSD-zlib-lib32: 15.0 -> 15.1 [FreeBSD-base]
        FreeBSD-zoneinfo: 15.0p7 -> 15.1 [FreeBSD-base]

Installed packages to be REMOVED:
        FreeBSD-lldb-dev: 15.0

Number of packages to be removed: 1
Number of packages to be installed: 10
Number of packages to be upgraded: 311

The process will require 2 MiB more space.

Proceed with this action? [y/N]: y
[empty.int.unixathome.org] [  1/327] Upgrading FreeBSD-bootloader from 15.0 to 15.1...
[empty.int.unixathome.org] [  1/327] Extracting FreeBSD-bootloader-15.1: 100%

...

[empty.int.unixathome.org] [326/327] Extracting FreeBSD-tests-dbg-15.1p1: 100%
[empty.int.unixathome.org] [327/327] Installing FreeBSD-set-tests-15.1...
==> Running trigger: mandoc.ucl
Generating apropos(1) database for /usr/share/man...
Generating apropos(1) database for /usr/share/openssl/man...
=====
Message from FreeBSD-local-unbound-15.1:

--
After upgrading local-unbound, the configuration file should be regenerated
by running "service local_unbound setup" before restarting the service.

Upgrade Third-party Kernel Modules

This is a jail, no need to do this, but it does run.

[22:45 r730-03 dvl ~] % sudo pkg -j $MYJAIL upgrade -r FreeBSD-ports-kmods
Updating FreeBSD-ports-kmods repository catalogue...
[empty.int.unixathome.org] Fetching meta.conf: 100%     179 B   0.2 kB/s    00:01    
[empty.int.unixathome.org] Fetching data: 100%    35 KiB  35.6 kB/s    00:01    
Processing entries: 100%
FreeBSD-ports-kmods repository update completed. 239 packages processed.
FreeBSD-ports-kmods is up to date.
Updating database digests format: 100%
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
[22:45 r730-03 dvl ~] % 

Check for Failed Configuration Updates

[22:48 r730-03 dvl ~] % sudo jexec $MYJAIL find /etc /usr/local/etc -name '*.pkgnew' -ls 

Then, I didn’t trust that it did it right, so I did it again.

[22:49 r730-03 dvl ~] % sudo jexec $MYJAIL
[22:50 empty root ~] # find /etc /usr/local/etc -name '*.pkgnew' -ls
[22:50 empty root ~] # 

Upgrade the Boot Loader

This is a jail, nothing to do here.

Finish

I reversed the jail configuration changes I made above, and then did:

[22:51 r730-03 dvl ~] % sudo service jail restart $MYJAIL                                   
Stopping jails: empty.
Starting jails: empty.

Done

This seems right:

[22:52 empty dvl ~] % freebsd-version -ur
15.1-RELEASE-p1
15.1-RELEASE-p1
Top

Canadian Man Pleads Guilty in Snowflake Extortions

Post by Brian Krebs via Krebs on Security »

A 26-year-old Canadian man once described as one of the most consequential cybercrime threat actors of 2024 has pleaded guilty to computer fraud and conspiracy to hack and extort more than 165 organizations that used the cloud provider Snowflake. Connor Riley Moucka, of Kitchener, Ontario, also admitted to stealing call and text history records of more than 100 million AT&T customers.

A surveillance photo of Connor Riley Moucka, a.k.a. “Judische” and “Waifu,” dated Oct 21, 2024, 9 days before Moucka’s arrest. This image was included in an affidavit filed by an investigator with the Royal Canadian Mounted Police (RCMP).

The U.S. Justice Department said between February and October 2024, Moucka and co-conspirators used stolen login credentials to steal cloud-hosted data belonging to at least 165 customers of a U.S.-based software-as-a-service company.

The hackers targeted stolen credentials for Snowflake customer accounts that did not enforce multi-factor authentication, and extorted or attempted to extort a host of well-known companies, including TicketMaster, Lending Tree, Advance Auto Parts and Neiman Marcus. Snowflake responded to the data thefts by increasing password complexity requirements and enforcing multi-factor authentication.

Moucka adopted new nicknames frequently — sometimes operating multiple identities concurrently — but two of his best-known monikers were “Judische” and “Waifu.” Judische’s admitted role in the Snowflake data thefts was first documented by KrebsOnSecurity in a September 2024 story about the overlap between Western, English-speaking cybercriminals and extremist groups that harass and extort minors into harming themselves or others.

That September 2024 story identified Judische as a software engineer from Ontario who has been involved in numerous data breaches and voice phishing attacks against U.S. companies since at least 2020. A little more than a month later, Canadian authorities arrested Moucka on a provisional warrant from the United States.

The government says Moucka and others used their unauthorized access to steal billions of sensitive customer records and download terabytes of information, “including individuals’ non-content call and text history records, banking and other financial information, payroll records, Drug Enforcement Administration (DEA) registration numbers, driver’s license numbers, passport numbers, social security numbers and other personally identifiable information. They then extorted victims by threatening to publish data online.”

Moucka also threatened and harassed government officials and security researchers who were helping to track him down. The Justice Department said the conspirators made over $2.5 million in ransom payments, and that in at least one instance, Moucka re-extorted a victim with threats of further disclosure of the victim’s stolen data.

“Moucka used the stolen data of a government officer and members of a then-former government officer’s immediate family in this re-extortion attempt,” reads a statement from the Justice Department.

One of Moucka’s admitted co-conspirators is Cameron “Kiberphant0m” Wagenius, a U.S. Army soldier who pleaded guilty in July 2025 to extorting AT&T and Verizon for their customer account data. Less than a month before Wagenius’s arrest, KrebsOnSecurity published a deep dive into Kiberphant0m’s various Telegram and Discord identities over the years, revealing how the owner of the accounts told others they were in the Army and stationed in South Korea.

One of several selfies on the Facebook page of Cameron Wagenius.

Kiberphant0m also re-extorted victims. Immediately following Moucka’s arrest, Kiberphant0m posted on hacker forums what he claimed were the AT&T call logs for then President-elect Donald Trump and for then Vice President Kamala Harris, as well schematics allegedly stolen from the U.S. National Security Agency (NSA).

Wagenius is set to be sentenced on September 3, 2026. The government says he faces a maximum penalty of 20 years in prison for conspiracy to commit wire fraud, a maximum penalty of five years in prison for extortion in relation to computer fraud, and a mandatory two-year sentence consecutive to any other prison time for aggravated identity theft.

The third alleged co-conspirator is John Erin Binns, 26, an elusive American man who fled the United States after being indicted for his admitted role in a 2021 breach at T-Mobile that exposed the personal information of at least 76 million customers.

Sources close to the investigation said Binns, also known as “IRDev” and “IntelSecrets,” was until recently incarcerated in a Turkish prison, but that he has since been released and has resurfaced online. Those sources said Binns also recently obtained Turkish citizenship, and under Turkish law a citizen cannot be extradited to a foreign country.

An image of a passport that Binns shared in an email to KrebsOnSecurity in Feb. 2023.

Moucka pleaded guilty to four criminal counts, including computer fraud, wire fraud, aggravated identity theft, and conspiracy. He is slated to be sentenced on Oct. 27 and faces a mandatory minimum penalty of two years in prison on the aggravated identity theft count, as well as a maximum penalty of 30 years in prison on the remaining counts. Ultimately, it will be up the federal judge how much time Moucka actually serves for his extensive cybercriminal rap sheet.

For an interview with Moucka prior to his arrest and a deeper look at Binns, see our original report on Moucka’s arrest.

Top

libexpat now funded by the City of Munich for up to 6 months

Post by Sebastian Pipping via Hartwork Blog »

For readers new to Expat:

libexpat is a fast streaming XML parser. Alongside libxml2, Expat is one of the most widely used software libre XML parsers written in C, specifically C99. It is cross-platform and licensed under the MIT license.

Starting 2026-08-01, the "security vacation" of the project has ended and(!) I will be be paid to work on maintaining libexpat for up to 6 months thanks to the City of Munich under the umbrella of their Open Source Sabbatical program.
What does that mean?

For much of the past 10 years, working on libexpat has been competing with my regular occupation as a software engineer, chores, social life and re-creation. For the first time, I am now being employed to work on maintaining libexpat as my "regular job" for a limited period of time. My top priorities will be:

Yesterday and today most of my time went into fixing a vulnerability uncovered by Mozilla.

Technically, I am being employed by digitial@M now for of up 6 months with a regular working contract, including cancellation by either party, remotely from home. There is plenty to do.

Unvalidated AI slop submissions will still not be apprecated, but for everything else: if you want to throw intelligence at finding further vulnerabilities in libexpat and send them my way, the coming months will be the best chance at getting things fixed in reasonable time. Queueing theory and laws of physics still apply.

Wish me luck!

PS: If anyone managed to combine Clang-based MinGW with AddressSanitizer and Wine without crashing at launch, please show me how and drop me an e-mail. Thank you!

Best, Sebastian

Top

Valuable News – 2026/08/03

Post by Vermaden via 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗 »

The Valuable News weekly series is dedicated to provide summary about news, articles and other interesting stuff mostly but not always related to the UNIX/BSD/Linux systems. Whenever I stumble upon something worth mentioning on the Internet I just put it here.

Today the amount information that we get using various information streams is at massive overload. Thus one needs to focus only on what is important without the need to grep(1) the Internet everyday. Hence the idea of providing such information ‘bulk’ as I already do that grep(1).

The Usual Suspects section at the end is permanent and have links to other sites with interesting UNIX/BSD/Linux news.

Past releases are available at the dedicated NEWS page.

UNIX

FreeBSD 2026 Q2 Status Report.
https://freebsd.org/status/report-2026-04-2026-06/

FreeBSD Git Weekly: 2026-07-20 to 2026-07-26.
https://freebsd-git-weekly.tarsnap.net/2026-07-20.html

Dockerbox Provides Docker on FreeBSD with Linux Bhyve VM.
https://github.com/leafoliage/freebsd-dockerbox
https://github.com/leafoliage/dockerbox-broker
https://github.com/leafoliage/freebsd-dockerbox-debian

ISC Licensed SMART Tool for FreeBSD.
https://github.com/ctuffli/smart

Migrating NAS from TrueNAS Core to Vanilla FreeBSD.
https://aumont.fr/posts/TrueNAS-to-FreeBSD/

Podman is Home Lab Ready on FreeBSD.
https://aumont.fr/posts/podman-freebsd/

Claude Code on FreeBSD is Game Changer for Self Hosters.
https://aumont.fr/posts/claude-code-freebsd/

Manage FreeBSD Jails Backup with NocoDB.
https://aumont.fr/posts/Jails-backup-nocodb/

Why Do I Run FreeBSD for My Home Servers.
https://aumont.fr/posts/FreeBSD-Home-Server/

FreeBSD Developing New NTSYNC Driver for Accelerating Windows NT Sync Primitives.
https://www.phoronix.com/news/FreeBSD-Q2-2026

Suricata/Jumbo Frames/Netmap on FreeBSD.
https://oshogbo.com/blog/93/

FreeBSD Just Removed Last of Its GPL Licensed Code.
https://hackaday.com/2026/07/28/freebsd-just-removed-the-last-of-its-gpl-licensed-code/

FreeBSD Kernel Still Has Some GPL Code While Userspace is GPL Free.
https://phoronix.com/news/FreeBSD-Bits-Of-GPL-Kernel

Code That Built Internet: Impact of BSD – Part 2.
https://lpi.org/blog/2026/06/26/code-that-built-the-internet-the-impact-of-bsd-part-2/

The syslog-ng Hardening Using Tor.
https://syslog-ng.com/community/b/blog/posts/syslog-ng-hardening-using-tor

Meet leaves(1) Terminal Disk Usage Visualization Tool.
https://github.com/patonw/leaves

How Unix spell(1) Ran in 64kB RAM.
https://blog.codingconfessions.com/p/how-unix-spell-ran-in-64kb-ram

Update on FreeBSD Journal – New Editor – No More PDF.
https://freebsdfoundation.org/blog/an-update-on-the-freebsd-journal-new-editor-new-format/

Making Postgres Queues Scale.
https://dbos.dev/blog/making-postgres-queues-scale

The mx Tool Adds FreeBSD Support.
https://github.com/graalvm/mx/pull/307

Xen 4.22 Released with AMD Zen 5 BLT Support and Improved RISC-V Virtualization.
https://phoronix.com/news/Zen-4.22-Released

LLVM Toolchain Coming to OpenBSD/sparc64 Arch.
https://undeadly.org/cgi?action=article;sid=20260730130302

FreeBSD Intern Working on Porting AMD ROCm to FreeBSD.
https://phoronix.com/news/FreeBSD-Intern-AMD-ROCm

Dead Software Walking: Ongoing Evolution of relayd(8) and httpd(8) on OpenBSD.
https://rsadowski.de/posts/2026/dead-software-walking-relayd-and-httpd/

SR-IOV is First Class FreeBSD Feature.
https://freebsdfoundation.org/sr-iov-is-a-first-class-freebsd-feature/

NetBSD 11.0 Released.
https://blog.netbsd.org/tnf/entry/netbsd_11_0_released

Announcing NetBSD 11.0.
https://netbsd.org/releases/formal-11/NetBSD-11.0.html

NetBSD 11.0 Released with RISC-V Support and Enhanced Linux System Call Compatibility.
https://phoronix.com/news/NetBSD-11.0

NetBSD 11.0 Brings RISC-V Support – Linux Compatibility Improvements.
https://linuxiac.com/netbsd-11-0-brings-risc-v-support-linux-compatibility-improvements/

MidnightBSD 4.0.7 RELEASE.
https://bsdsec.net/articles/midnightbsd-security-midnightbsd-4-0-7-release

HardenedBSD 2026/06-07 Status Report.
https://hardenedbsd.org/article/shawn-webb/2026-07-31/hardenedbsd-june-july-2026-status-report

Why I am Going Back to tmux(1) From zellij(1).
https://stevengharms.com/posts/2026-07-31-why-im-going-back-to-tmux-from-zellij/

NetBSD 11 Brings Updated UNIX Support to AMIGA 68k and PowerPC.
https://generationamiga.com/2026/08/02/netbsd-11-brings-updated-unix-support-to-amiga-68k-and-powerpc/

UNIX/Audio/Video

FreeBSD Eliminated All Its GPL Code.
https://youtube.com/watch?v=jmWq0gMx20o

Enable ZFS Autotrim on GhostBSD.
https://youtube.com/watch?v=PVh0buX_Fjc

BSD Now 674; Software Development Never Changes.
https://www.bsdnow.tv/674

Hardware

First Open Source Firmware Released for Modern AMD Ryzen AM5 Platform.
https://phoronix.com/news/OSS-Firmware-MSI-B850-P-WIFI

AMD Posts Linux Patches for HDMI 2.1 Auto Low Latency Mode ALLM and VRR.
https://phoronix.com/news/AMDGPU-HDMI-2.1-ALLM

How Does Processor Work?
https://hwcooling.net/en/how-does-a-processor-work-intended-for-secondary-schools/

Life

Is AI Company Buying Up All Used Books?
https://charliebecker.substack.com/p/is-an-ai-company-buying-up-all-the

This is How You Start Over.
https://youtube.com/watch?v=gmVyA5SUj9I

System Administrator Appreciation Day.
https://micski.dk/2026/07/31/system-administrator-appreciation-day-2/

Sysadmin Day 2026.
https://evilham.eu/en/blog/2026-sysadmin-day/

Other

MPEG-4 Patent Expiration – RADV on Windows – Open Source AI.
https://phoronix.com/news/July-2026-Highlights

Razor 1911 Demo Bytes of Art.
https://vivianvoss.net/blog/bytes-of-art-razor1911

Razor 1911 – Windows Demo.
https://youtube.com/watch?v=lILxp5c3bis

Paged Out – Issue #9.
https://pagedout.institute/webview.php?issue=9&page=1

Usual Suspects

BSD Weekly.
https://bsdweekly.com/

DiscoverBSD.
https://discoverbsd.com/

BSDSec.
https://bsdsec.net/

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

BSDTV.
https://bsky.app/profile/bsdtv.bsky.social

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

BSDJedi.
https://youtube.com/@BSDJedi/videos

RoboNuggie.
https://youtube.com/@RoboNuggie/videos

GaryHTech.
https://youtube.com/@GaryHTech/videos

Sheridan Computers.
https://youtube.com/@sheridans/videos

82MHz.
https://82mhz.net/

EOF
Top

Post by FreeBSD Newsflash via FreeBSD News Flash »

New committer: Faraz Vahedi (src)
Top

HardenedBSD June / July 2026 Status Report

Post by HardenedBSD via HardenedBSD »

This status report covers both June and July 2026. It has been a rather chaotic couple of months for me.

I am going to use quite the number of backticks (`) in this status report. I apologize in advance. Think of then as used in Markdown to convey a command or static text.

In my announcement about force pushing the ports branch: I neglected to clarify the underlying issue and who is impacted. So, a non-malicious less-than-desireable commit made its way to the FreeBSD ports tree. FreeBSD needed to effectively remove the offending commit from the history due to licensing issues (there could be additional factors to which I am not privvy.) Since further commits made it to the tree, this made recovering from that state
a bit more difficult.

This naturally caused a chain reaction downstream for us. In addition to FreeBSD's commits, I had made multiple commits to migrate some of our ports entries to Radicle. This means that, we, too, have to break git commit history.

Those downstream from HardenedBSD, even, could be further impacted in a similar fashion. Those impacted primarily are those who maintain their own patches atop our ports tree. HardenedBSD uses a merge-based workflow for bringing in changes from upstream. I recognize that there may be downstream users who use a different workflow. I cannot advise you in that case--I'm most familiar with a merge-based workflow and haven't been sufficiently motivated to try others.

What I did was `git reset --hard` the tree back to the HardenedBSD auto-sync merge commit just prior to the offending commit from upstream. Afterwards, I merged the new freebsd main HEAD commit to our hardenedbsd/main branch.

If the last time you updated your ports tree was in the period we accepted the bad commit and our subsequent rollback, but you do NOT carry patches, you might find yourself in a weird state. I'm unsure what to tell users who use `git pull`, since I use a `git fetch && git merge` model. So, if you use the same, you can simply `git reset --hard rad/hardenedbsd/main` (after fetching `rad` of course).

I did run into issues with Radicle: primarily issues with mental models for this kind of situation. Previously, I consdiered the `rad` remote (which Radicle sets up by default) to be okay to use for both fetching and pushing. I used it like I would any normal git remote with push access.

Instead, I really should have considered the `rad` remote as read-only: use it only for fetching. I instructed Radicle to create a new remote, pointed to my own Radicle node: `rad remote add --name self $(rad self --did)`. I should push to this new remote, named `self`. For a more nuanced discussion, please see Appendix A below.

I haven't forgotten about re-establishing our GitHub mirror. I have other higher priority tasking at the moment, but I just wanted to say it is not forgotten. (And, I'm somewhat glad that our GitHub mirror hasn't been updated, since it hasn't been updated in so long, it didn't see the bad ports commit.)

In src:

  1. Robert set the default VMSIZE to 80gb for release VM images
  2. Shawn Webb: Harden the new security.bsd.allow_tiocsti sysctl node
  3. Shawn Webb: rc.conf(5): Support custom values for KLD prohibition value (hbsd_late_kld_prohibition_value, default: 1)
  4. Shawn Webb: Harden security.bsd.unprivileged_kenv_read
  5. Shawn Webb: Enable stack auto-init to zero for the linuxulator
  6. Shawn Webb: jail(8): Use safer memory management APIs
  7. Shawn Webb: Enable -ftrivial-var-auto-init=zero for linuxkpi_{hdmi,video}
  8. Shawn Webb: HBSD: Harden new sysctl nodes and reorganize PTrace hardening
    1. Harden vm.phys_fictitious_segs sysctl node with CTLFLAG_ROOTONLY
    2. Harden ptrace(PT_SET_SC_RET) in the same fashion as ptrace(PT_SC_REMOTE)
  9. Shawn Webb: Enable trivial var auto-init for uvideo(4)
  10. Shawn Webb: Enable -ftrivial-var-auto-init=zero for opensolaris.ko
  11. Shawn Webb: Garbage collect unused sysctl node
  12. Shawn Webb: Harden the GEOM and related control interfaces

In ports:

  1. Robert added a new port: misc/robert
  2. Robert migrated misc/robert to Radicle
  3. Robert updated the misc/robert port a few times, currently sitting at version 0.10.0.
  4. Robert migrated hardenedbsd/ctrl to Radicle
  5. Shawn Webb disabled COMPAT32 for the following ports:
    1. misc/compat13x
    2. misc/compat14x
    3. misc/compat15x
  6. Shawn Webb fixed the build of graphics/mesa-libs
  7. Shawn Webb fixed the build of graphics/mesa-dri
  8. Shawn Webb fixed the python version used with net-p2p/reticulum
  9. Shawn Webb fixed the build of lang/zig015 (which has, as of this writing, is broken again and on my queue to figure out.)
  10. Default devel/wasi-libc to llvm 21
  11. Migrate the default llvm version to 21 globally now that 15-STABLE LLVM in base has been updated to llvm 21
  12. Update ports-mgmt/pkg to 2.8.1
  13. Migrate hardenedbsd/liblattutil to Radicle
  14. Migrate hardenedbsd/hbsdmon to Radicle
  15. Migrate net/libpushover to Radicle
  16. Migrate sysutils/vm-bhyve-hbsd to Radicle and update to 1.7.4 (from 1.5.0)

Appendix A

Note: Relevant Zulip discussion

It is suggested that if you plan to contribute to a repository, you create a new remote called `self`: `rad remote add --name self $(rad self --did)`. Fetch from `rad`, push to `self`.

Treat `rad` as a virtual peer/contributor that tracks the network consensus and `self` is where you do all your own work.

Your `self` is what others see when they `rad remote add` you, and vice versa, so they're good for ad-hoc sharing. `rad` looks around at everybody and gathers up the crefs that satisfy sig requirements, so it's where you fetch canonical state from. As a convenience, `rad` also gathers up all the open patches so you don't have to hunt them down in the specific remote they came from.

Top

Suricata, Jumbo Frames, and netmap

Post by Mariusz Zaborski via oshogbo web »

One of my FreeBSD machines sits between the Internet and the rest of my network. I wanted Suricata to monitor traffic arriving on four of the machine's interfaces and complain when something looks wrong. I started with one interface, `mce1`, and planned to add the other three after capture worked. The capture interfaces are backed by Mellanox ConnectX adapters handled by the mlx5en driver, and they use a jumbo-frame MTU of 9000 bytes.
Top

Read This Before You Buy That TV Streaming Stick

Post by Brian Krebs via Krebs on Security »

Security experts have been sounding the alarm for years about the risks of using generic TV boxes that promise unlimited content streaming for a one-time fee, warning that they secretly rent the user’s Internet connection out to strangers. But a groundbreaking new analysis finds these devices also routinely spoof themselves as mobile phones clicking ads on AI-generated websites as part of a sprawling operation that seeks to defraud online merchants and advertising networks.

Pedro Falé is a threat researcher with the security firm Bitsight. Falé told KrebsOnSecurity he was able to peer inside a vast and complex ad fraud network by registering an expired domain name that was used to coordinate fake ad clicks across a particularly popular brand of these streaming devices known as H96.

An H96 TV streaming device currently advertised for sale on Amazon.

Falé said the domain he scooped up was previously used for telemetry, periodically collecting full hardware information and the entire list of installed apps from tens of thousands of H96 streaming sticks plugged into television sets around the globe. But upon inspecting the traffic being funneled to the domain, he discovered nearly all of the TV boxes transmitting data claimed to be mobile phone models from a variety of manufacturers, including Samsung, Vivo, Huawei, and Xiaomi.

“We noticed something was wildly wrong,” Falé said. “Multiple devices reporting to this factory Android TV Box backdoor were ‘phones.'”

Image: Bitsight.

The researcher found all of the devices reported having the same two apps installed, and that those apps were made by a company called Zhejiang Fengwo IoT Technology Ltd, an entity founded in 2019 in mainland China which operates an ad-publishing portfolio under the name Fengwo Group. Further investigation into the Fengwo Group revealed it has registered multiple patents that match the inner workings of these apps.

“Bitsight TRACE identified several Hong Kong, Singapore, and single person ‘legal’ shell identities used to collect the monetization and traced the operation back to a mainland China company known as Zhejiang Fengwo IoT Technology Co., Ltd, which operates under the Fengwo Group,” Falé wrote in a report released today about their findings.

Falé said an analysis of the apps shows they help to coordinate an ad fraud network that uses these H96 devices as a captive traffic source to click on ads at AI-generated websites operated by the Fengwo Group.

Bitsight discovered the websites contain machine-generated news articles and graphics across a range of categories, including finance, health, education, gaming, music and food blogs. But they also found none of those sites displayed ads unless the device visiting the page matched the spoofed mobile profile of these H96 devices.

AI DIGITAL HUMANS

The domain for the Fengwo Group — fwgcloud[.]com — claims the company is “redefining the boundaries of human-AI interaction,” and that it has created more than 120,000 “AI digital humans” available to rent for everything from emotional companionship to 24/7 customer service and creative design.

The homepage for fwgcloud dot com.

Falé said the Fengwo Group’s domain shared its SSL certificate data with other domains associated with the apps found on H96 devices, specifically the phone spoofing mechanism. He noted the domain also has an internal wiki platform that directly ties the Fengwo Group to a proprietary implementation of a Google-built visual programming language called Blockly, which was originally designed to help kids learn how to write software.

According to Bitsight, the Fengwo Group’s employees use Blockly to build the sham websites, allowing low-skilled operators to drag blocks of code together in their Blockly editor — without any need to understand what the underlying code blocks do or how they work.

The Blockly homepage.

“An operator can drag blocks together in their Blockly editor, to define each fraud routine, given a task type,” reads Bitsight’s report. “Once the routine is saved, it gets exported as JavaScript and uploaded to the S3 buckets. An operator doesn’t need as much understanding of the underlying technicalities, as it is all set in place for ease of use.”

Bitsight even found one of the Fengwo Group app developers mentioning exactly these advantages, noting the developer remarked that “only a small number of highly-skilled developers are needed to build the template execution-unit images,” and that “developers who create execution units from those templates have significantly lower technical requirements, greatly reducing the company’s operating costs.”

Falé said if a user’s H96 streaming stick is selected for a specific fraud task, it will be pushed the appropriate Blockly module according to the task desired, which can include silently launching a web browser, visiting websites, browsing pages, managing tabs, and clicking on ads.

To ensure the TV boxes masquerading as mobile phones can reliably click on ads displayed via the AI-generated websites, the Fengwo group “fuses three vision and reasoning systems into a single interface,” allowing the bots to correctly identify an ad on the webpage and navigate the site much like a human would, the Bitsight report observed.

Examples of ad landing pages linked to the Fengwo Group. Image: Bitsight.

TV ON? PROXY. TV OFF? AD FRAUD

Bitsight found the H96 devices were either relaying residential proxy traffic or participating in ad fraud, but never both at the same time. In fact, they concluded that when these TV boxes detect an HDMI signal from an attached television — indicating the user intends to stream video content — the box is usually functioning as a residential proxy. When the TV is off, it switches back to waiting for ad fraud jobs.

Falé said he believes the TV boxes are set up this way because its ad fraud activities are far more resource intensive and could interfere with the device’s stated purpose — streaming video content over the Internet.

Despite repeated warnings from the FBI and security industry leaders about the security and privacy risks of using these streaming devices, major e-commerce providers like Amazon, Best Buy, Newegg and others continue to sell hundreds of different models and brands that bundle unofficial versions of Google’s Android operating system and are frequently marketed (via online influencers) as a way to access a broad array of streaming services and live broadcasts without a subscription.

Image: fbi.gov.

In addition to enlisting the user’s TV box in ad fraud networks, these off-brand streaming devices almost universally come with residential proxy software pre-installed. This software rents the user’s Internet address out to anonymous paying customers, who run the gamut from aggressive content scraping firms to ticket scalpers and outright cybercriminals.

What’s more, because these generic (and generally dirt cheap) TV boxes are all horribly insecure by default and bereft of any kind of authentication, installing one on your home or office network only invites further mischief. In January, the proxy tracking service Synthient documented how multiple botnets had rapidly enslaved millions of TV boxes using a complex interplay of security vulnerabilities in both the residential proxy software and the streaming devices themselves.

SHOW ME THE MONEY

Bitsight said it tracked approximately 38,000 TV boxes globally phoning home to the expired Fengwo Group domain, and based on that number the report estimates this ad fraud network brings in revenues of close to $50,000 a day (not counting substantial revenue from the residential proxy side of the business). However, Falé emphasized that these estimates are highly conservative and based on telemetry from just one of the Fengwo Group’s core (but older) domains.

As for the Fengwo Group’s claim to have 120,000 “digital humans” at their disposal, Bitsight’s report concludes it could be just a clever marketing scheme and/or a way to avoid drawing suspicion to the company’s operations.

“Historically, when dealing with proxy services or DDoS, we sometimes see these websites undertake inconspicuous facades, so as not to advertise their DDoS capability or botnet size,” Falé wrote in the report. “This could also be the case here.”

If the Fengwo Group truly does have tens of thousands of “AI humans” at its beck and call, it does not appear to have dedicated any of them to fielding inquiries from its own website. KrebsOnSecurity sought comment from the Fengwo Group by emailing the contact address listed on the company’s homepage, but the request bounced back with the reply, “Your message couldn’t be delivered to postmaster@fwgcloud[.]com. Their inbox is full, or it’s getting too much mail right now.”

As Bitsight’s analysis shows, when it comes to TV boxes and streaming sticks, it’s best to stick to name brands from reputable manufacturers, and then to be sparing and careful with any apps you choose to install on the device — as many of those can bundle residential proxy software as well. Google says consumers can confirm whether or not a device is built with the official Android TV OS and Play Protect certification by following these instructions.

Additionally, Synthient maintains a running list of IoT devices that have been known to ship to consumers with residential proxy software and other malicious apps pre-installed. Careful readers will notice Synthient’s list includes other IoT devices apart from streaming sticks and boxes: As the FBI has warned, residential proxy software has also been found in other popular consumer IoT devices from random brands, particularly digital photo frames.

Top

An Update on the FreeBSD Journal: New Editor, New Format

Post by FreeBSD Foundation via FreeBSD Foundation »

We have a couple of updates to share about the FreeBSD Journal.

A New Editor

Please join us in welcoming Matt Slaybaugh as the Journal’s new editor. Matt brings years of editorial and content management experience, including his ongoing work with the Association for Computing Machinery (ACM), and he’s already hard at work on upcoming issues.

 

A Streamlined, Browser-Based Format

You may have noticed that our latest issue, Improving Software Quality, was only available in HTML, with no downloadable PDF. That wasn’t an oversight. Going forward, the Journal is moving to a browser-based-only format: the same great content, delivered directly on our website.

We know some of you will miss having a PDF to save or read offline, and we appreciate hearing that feedback. Streamlining how we produce the Journal lets our small team put more energy into the content itself: recruiting authors, editing articles, and keeping the Journal free for everyone, which remains a top priority.

What Stays the Same

Everything else about the Journal continues as it has: published quarterly, always free, and guided by our editorial board, chaired by John Baldwin, and our advisory board. You can read every issue on our Browser-Based Edition page.

Questions about the transition? Reach out to Matt directly at journaleditor@freebsdfoundation.org.



The post An Update on the FreeBSD Journal: New Editor, New Format first appeared on FreeBSD Foundation.

Top

Post by FreeBSD Newsflash via FreeBSD News Flash »

New committer: Minsoo Choo (src)
Top