When setting up a fresh system like my Lenovo ThinkPad T450 (named
taylor) running Fedora Linux 44 (Workstation Edition), transferring
cryptographic identities safely is a top priority. When hardening SSH, the
strictness of file permissions is enforced directly by OpenSSH's
StrictModes check. If permissions are too open, SSH will
reject key usage with errors like permissions being too open.
OpenSSH Permission Requirements
Here are the minimal and recommended permissions required for secure SSH
key directory and file operations on your system.
The SSH Directory (~/.ssh)
Minimal/Recommended Permission:700 (drwx------).
Access Level: Only the file owner can read, write, and execute the
directory, leaving group and others with zero access.
Ownership: Must be owned by the active user account utilizing the
keys.
chmod700~/.ssh
chown-R$USER:$USER~/.ssh
Files Within the SSH Directory
Permissions vary depending on whether the file contains private data,
public data, or configuration settings:
Private Keys (id_ed25519, id_rsa): Mode 600 (or 400) for
owner read/write or read-only access, barring all others.
Public Keys (id_ed25519.pub, id_rsa.pub): Mode 644 allowing
owner read/write and group/others read-only access.
Authorized Keys (authorized_keys): Mode 600 for owner
read/write only.
Config / Known Hosts (config, known_hosts): Mode 600.
Note
For private key files, the absolute minimum required permission for
standard SSH operations is 400 (-r--------). However,
600 is standard because it allows updating configurations without
modifying permission bits first.
Parent Directory Constraints
OpenSSH also validates the permissions of parent directories in the path
leading up to ~/.ssh. Your home directory must not be
writable by group or world, with a maximum allowable mode of 755 or
750. If the home directory has overly open permissions, SSH
will refuse key authentication even if ~/.ssh is set to 700.
chmod750/home/$USER
Backing Up and Restoring via External USB
To transfer your .ssh directory to an external USB drive from Fedora
44 and later restore it to taylor, standard copying tools can cause
ownership mismatches or strip permission bits. Using rsync
with the -p (--perms) flag ensures permission bits transfer
intact while writing files directly under your current logged-in user.
Using rsync for Backup and Restoration
Assuming your USB directory mount path points to your target location, run
the copy operation while preserving permissions:
After restoring your keys to taylor from the USB drive, perform a
post-copy safety check and apply mass hardening commands to satisfy OpenSSH
strict mode checks.
Inspection and Hardening Commands
Verify file permissions and apply the mass hardening script:
# 1. Inspect restored files
ls-la~/.ssh
# 2. Set directory to 700 and private keys to 600
chmod700~/.ssh
chmod600~/.ssh/id_*2>/dev/null||true
chmod644~/.ssh/*.pub2>/dev/null||true# 3. Ensure proper user ownership
chown-R$USER:$USER~/.ssh
Establishing Remote SSH Key Authentication
To connect from another machine—such as your MacBook Pro (running macOS)—to
your Lenovo ThinkPad taylor (running Fedora 44) using SSH keys, you need
to configure network access, verify the SSH daemon, and copy your public
key.
Step 1: Find the IP Addresses
First, identify the local IP addresses of both systems.
On your Lenovo ThinkPad (Fedora Linux), open a terminal and run:
hostname-I
(Alternatively, use ``ip a`` and look for the ``inet`` address under your
Wi-Fi or Ethernet interface).
On your MacBook Pro (macOS), open Terminal and run:
ipconfiggetifaddren0
(If connected via Wi-Fi, ``en0`` is typically your Wi-Fi interface).
Step 2: Ensure SSH Server is Running on Fedora
Before copying your key, ensure your ThinkPad allows incoming SSH
connections. On your ThinkPad, run:
# Check if SSH daemon is active
systemctlstatussshd
# If it is not active, start and enable it:
sudosystemctlenable--nowsshd
# Ensure Fedora's firewall allows SSH traffic:
sudofirewall-cmd--add-service=ssh--permanent
sudofirewall-cmd--reload
Step 3: Copy Your Key from MacBook Pro to ThinkPad
Because your key file may have a custom name (such as
porfirio@altair.pub instead of the default id_ed25519.pub), you must
pass the -i flag to specify it.
Run this command from your MacBook Pro Terminal (replace username with
your Fedora username and 192.168.1.50 with your ThinkPad's IP):
Confirm the connection prompt by typing yes and hitting Enter.
Enter your Fedora user password when prompted.
The key will be installed into ~/.ssh/authorized_keys on your
ThinkPad.
Step 4: Configure ~/.ssh/config on Your MacBook Pro
Since your key file has a custom name, macOS will not automatically use it
when running a standard SSH connection. To make connecting seamless, add
an entry to your ~/.ssh/config file on your MacBook Pro:
Open the configuration file on your Mac:
nano~/.ssh/config
Add the following host block:
Host taylor
HostName 192.168.1.50
User username
IdentityFile ~/.ssh/porfirio@altair
(Replace ``192.168.1.50`` with your ThinkPad's IP and ``username`` with
your Fedora account name).
Save and exit (Ctrl + O, Enter, then Ctrl + X).
Step 5: Test Passwordless SSH
Now, from your MacBook Pro, you can connect passwordlessly by running:
sshtaylor
Finishing Touches
With these steps completed on Fedora 44, your SSH keys are safely backed
up, restored, and fully optimized for secure remote connections.
On September 22 we released systemd v262 into the wild.
In the weeks leading up to that release (and since then) I have posted
a series of serieses of posts to Mastodon about key new features in
this release, under the
#systemd262
hash tag. In case you aren't using Mastodon, but would like to
read up, here's a list of all 35 posts:
I intend to do a similar series of serieses of posts for the next
systemd release (v263), hence if you haven't left tech Twitter for
Mastodon yet, now is the opportunity. My series for v263 will begin in
a few weeks most likely, under the
#systemd263
hash tag.
Py (daughter) is still struggling to read Bengali text, as she was not reading it everyday. And on top of that Bengali script has many complex Bangla (Bengali) conjuncts (ক্ষ, জ্ঞ, ষ্ণ, ঙ্ক), and Py could not remember all the characters and had to go back and find them.
So now I am using https://ektubangla.org where anyone (a teacher/ parent) can click to "Create a session" and type in any Bengali text, and the students/readers can see the reader board where each word is broken into letters, so that the new reader can easily pick up what those letters are.
The conjuncts are also colored differently in the text and broken into letters properly. Py is super happy to use to read much longer texts. I hope this will be helpful for more parents/teachers.
This year’s edition of International Calligraphy Festival Keralam was yet another great experience, consisting of workshops, demonstrations and talks surrounding calligraphy & typography, much like the last time. Eminent calligraphers of about a dozen scripts shared their expertise and experience.
Pictures of a sample collection of the calligraphy works at the exhibition below.
For my talk, I presented the historical evolution of Malayalam script from rock inscriptions to the digital age, and how the vigilant volunteer community reclaimed the script with its rich conjuncts and conjoined reph/matra shapes, and made all the foundational digital technologies openly available for public good.
Many type designers, companies and enthusiasts were also at the 4-day programme, enabling lot of productive hallway talks as well. A recurring question was the usage of Open Font License, which I hope to have helped to clarify.
The most useful feedback after the talk came from a good friend, who pointed that my slides didn’t do enough justice to the body of work we’ve done (particularly as open-source); and helped me walk through some possible improvements. I did make some of those changes, and the slides (created using TeX) are made available.
Cloning Test Plans just got an upgrade in Kiwi TCMS v16.6! Whether you want
to duplicate a single plan, a whole handful of them, or an entire nested tree, the new
cloning workflow keeps your clicks to a minimum.
Here are the 3 changes we shipped:
1. Clone names now carry the original ID
When you clone a Test Plan the suggested name now includes the original ID,
so the lineage of every copy is obvious at a glance:
The Clone of TP-117: prefix is highlighted above. Rename it if you like - but the default
now tells you exactly where the copy came from! This feature is intended for the human behind
the computer! Feel free to change the new name to whatever fits best in your case.
2. Multi-clone from Search Test Plans page
Need to duplicate a batch? The Search Test Plans page now displays a checkbox column
on the lefthand side and the cloning button has joined the buttons row in table header:
Selection is explicit - you tick exactly the records you want - and the clone page
displays all of them at the same time. Name, Product, Version, etc are individually
adjustable per row:
This functionality was built on top of contributions from
Oskar Hurst, U.S. Army Corps of Engineers. Thank you Oskar!
3. Deep clone an entire Test Plan tree
Parent/child relationships can now be preserved when cloning!
The cogs menu now offers the Deep clone item which
will clone the entire relationship structure starting at the current Test Plan:
The clone page then lays out the whole tree. Each clone keeps its ID-derived name and you
get visual level indicators so the hierarchy stays readable while you review it:
When deep cloning, the on/off button used to adjust the parent of individual Test Plans is
disabled. The structure is cloned as-is on purpose, so there is nothing to re-parent
while the tree is being copied!
Happy Testing!
If you like what we're doing and how Kiwi TCMS supports various communities
please help us!
Découvrez les nouveautés de SeedboxSync v4.3 : migration vers Bootstrap, refonte du dashboard et des statistiques, rendu CLI modernisé avec rich.table, ajout d'un widget pour Homepage et correction d'un bug critique sur les arborescences profondes.
Retour d'expérience sur ma migration vers Fedora 45 bêta sur mon laptop Asus : mise à jour fluide, déplacement des fichiers de configuration des dépôts vers /usr/share/dnf5/repos.d, migration de mes paquets Copr, bascule de mes Flatpaks du système vers le profil utilisateur et sélection de quelques indispensables.
It wasn't just a single, off-the-cuff comment on social media
The comments were repeated by all the key leadership figures in the party/cult
The comments were repeated throughout the whole campaign, right
up to voting day
Now, even in a legal procedure, they admit offering money to
the Acting Returning Officer
Through their enthusiasm, which we can see in the videos, we can
see they are incredibly sincere about this offer of money.
The offer was made publicly, through every media channel willing to
speak to them, knowing they would reach as many people as possible
and the offer were be recorded online, like a signature on paper.
There is a big burst of publicity about this offer in the week when
Nigel announced the by-election. This offer was made well before the
close of nominations, which only occurred on 17 July 2026.
Related points:
Representation of the People Act 1983, s29(1) "No consideration shall be given by or to a returning officer for the making out, receipt, delivery or return of the writ for a parliamentary election or, subject to the following provisions of this section, otherwise in connection with its execution.". In other words, Nigel Farage's admission that he offered to give money to the CEO of Tendring District Council appears to be a conspiracy to violate Representation of the People Act 1983, s29(1).
Under British penal law, it is not necessary for an offender to follow through on the conspiracy for it to be a crime. The intent alone constitutes the crime of conspiracy.
When watching the entire cast of the Nigel Farage freak show all taking their turn to make promises about violating s29(1), we need to ask if their collusion in this matter and their apparent desparation to follow through on this hairbrained scheme violates the more serious crime of conspiracy.
After the election, Mr Pocock sent a Freedom of Information request to Tendring District Council asking for records of the proposation Mr Farage made to the CEO. So far, those records have never been given to Mr Pocock.
Representation of the People Act 1983, Schedule 1, 17(1) "If the statement of persons nominated shows more than one person standing nominated, a poll shall be taken in accordance with Part III of these rules.". In other words, if no other candidates nominate, there is no election. Therefore, the payment of the £500 election deposit by at least one rival candidate is an unavoidable expense for the promised election to take place. On these grounds, Reform UK has promised there would be an election, all the big parties refused to participate in an election and therefore, Reform UK actually needed to have some Nobodies or there would not have been an election at all.
The point about the criminal code on conspiracy should not be
underestimated. If Mr Farage was the only person who mused about
such payments then it would not be a conspiracy because conspiracy
is a multi-person crime. The fact the
Reform UK leadership team are all singing from the same hymn book
demonstrates multiple people are telling us they are unified with the
intention to make some kind of payment contrary to RPA 1983 s29(1).
We need to drill down on this. There is a lawsuit in progress
already but we are prohibited from talking about it.
I have spoken to the CEO of Tendring District Council. Reform has
offered to cover the cost of the by-election.
I will be writing to Rachel Reeves later today with the same message.
Given that we asked for this by-election in the first place, it's only right that we pay for it.
Nigel never gave us a record of his discussion with the CEO of
Tendring District Council. He never published the letter sent to
Rachel Reeves, who was Chancellor of the Exchequer at the time
Nigel made this offer to pay.
Count Binface had the impression payments to other candidates were
in scope and he replied:
Count Binface:
Nige, if you want to cover my travel costs from Sigma IX, you can pop five million quid here: ko-fi.com/countbinface
Yesterday I open sourced Integrum, a library that is a part of AlphaDeep world. It allows you to quickly create MCP server(s) from existing Python libraries or modules (or even plain classes!). It is released with MIT license and I hope somebody else also finds it useful for a more formal approach to giving agents additional capabilities (compared to just letting them writing arbitrary code with or without a sandbox).
Obviously not all Python code is functional, so some state management is required. I opted for a simple in memory object store pattern with keys being “model-friendly” -> they are words to save tokens. Also there is tuple unpacking, array access and other simple needed things to get started.
LLM sessions are stateless by design so I thought it would be hard to keep track of which object belongs to which user. Luckily after inspecting FastMCP implementation it seems like context is present (for HTTP/SSE anyway) so that didn’t turn out to be that difficult in the end.
To test Integrum out I gave Gemma 4 (26B A4B) access to scikit-learn Random Forest Classifier and a toy dataset (Iris). Without much trouble Gemma was able to build and evaluate a small model. It didn’t experiment with hyperparameter tuning but since it got 100% validation accuracy it didn’t have the opportunity.
It would be interesting to see what it would do with a “hard” problem. It would also be interesing if we gave it tools to update its own weights to improve performance on some benchmark. :)
AssertHired is a mock interview and upskilling platform built only for
QA engineers and SDETs. You answer real QA interview questions, typed or out loud,
and an AI interviewer asks follow-ups the way a hiring panel would. Every answer is scored on
technical accuracy, communication, use of examples, and depth.
Then you see what a stronger answer would have covered.
It was built by Aston Cook - a Senior QA Automation Engineer with more than ten years in
test automation who’s run more than 50 QA interviews as the person making the hiring decision.
AssertHired grew out of my own interview prep for loops at Amazon, Microsoft and Google.
Every time, the material was either too generic or too shallow. Nothing gave me realistic
practice with the questions QA interviewers actually ask, graded by someone who has sat on
both sides of the table. So I built it.
What is AssertHired's relation to open source?
The product itself is commercial, but it stands on open source so I publish what I can. For example:
asserthired-evals: a reference evaluation suite
for AI interview grading. A synthetic golden dataset, seven CI-gated metrics, LLM-as-judge graders,
a red-team suite, drift detection and judge calibration.
changelog-mcp: an MCP server that logs user-visible
product changes and grades them later. It's for solo operators who can't run A/B tests.
What makes developing AssertHired challenging?
Testing the AI. The grader has to give the same answer the same score, and that score has to line up
with what a real panel would say. Classic assertions don't work on non-deterministic output,
so I built an eval harness. Any change to a prompt ships with eval coverage in the same pull request.
How do you approach testing at AssertHired?
The same way I'd approach it anywhere: in layers, aimed at the risks that cost users something.
Vitest for unit, integration and component tests
Playwright end-to-end tests for the flows that matter most, like signing up,
taking an interview and checking out. They run in CI
An eval harness for the AI, with golden cases and CI-gated metrics
Incidents turn into checks. A database permissions bug once reached production,
so now CI fails the build if code writes to a column the user's role isn't allowed to write
A guard in the test suite that makes it impossible for a test to send a real email.
Test cases live in code, next to the features they cover.
Tell us about your Kiwi TCMS Interview Questions page?
It's one of over 70 interview question pages, which cover what interviewers ask at
junior, mid and senior level - the common questions, and a way to practise them out loud.
At present it covers 12 questions and is located at
https://www.asserthired.com/interview-questions/kiwi-tcms.
Why did you decide to write about Kiwi TCMS?
The topic of test management comes up in QA interviews all the time,
and Kiwi TCMS is a strong open-source option. Candidates can run it on their own and learn
how plans, cases, runs and executions fit together, and how automated results get in.
This is exactly what the interview questions probe.
For Kiwi TCMS, my favourite question is:
You try to add a test case to a test run and it won't go in. Why?
hint: only confirmed cases can be added to a test run
What do you think about QA and AI? What do you use AI for, and what doesn't work for you?
I use it every day. It's good at first drafts: test cases, test data, boilerplate.
It's good at reading a long log or stack trace and pointing at the line that matters,
and at explaining unfamiliar code. I also use it heavily to write code.
It's a big part of how one developer can run a web app and its iOS and Android apps.
However it doesn't know what matters to your business, and it rarely says it's unsure.
It will happily write a test that passes for the wrong reason. So everything it produces gets
reviewed like a pull request from someone new to the codebase, and anywhere being confidently
wrong is expensive, a person decides.
The bigger shift for QA is testing AI features themselves. You can't assert on an exact string
when the output changes every run. You need golden datasets, graders, and metrics that gate the build.
I learned that building AssertHired's own grader, and I think it's the most valuable new skill
a tester can pick up right now.
If you like what we're doing please help us grow and sustain development!
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.
RPMs of PHP version 8.5.12RC1 are available
as base packages in the remi-modular-test for Fedora 43-45 and Enterprise Linux≥ 8
as SCL in remi-test repository
RPMs of PHP version 8.4.27RC1 are available
as base packages in the remi-modular-test for Fedora 43-45 and Enterprise Linux≥ 8
as SCL in remi-test repository
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.
Log Detective has not been used as a CLI tool for quite some time, especially
since the release of v4, where the server’s /analyze endpoint was rewritten
to an agentic workflow built with
beeai-framework.
All dependent services (Log Detective website,
Packit, Copr, etc.) utilize the /analyze endpoint on Log Detective servers,
since our production offers a larger model, giving better and faster responses.
The original idea for the Log Detective CLI tool was that someone could
run a custom, locally hosted LLM fine-tuned to their specific use case,
provided they had enough data.
In practice, not many people (that we know of) followed through with this,
instead relying on the server we maintain.
The Log Detective CLI thus slowly began to feel like more of a
maintenance burden, often duplicating some functionality between
server and CLI, and requiring extra architectural complexity to cater to both.
Now, we are in the middle of adapting our codebase to also analyze
test logs from Testing Farm, a big step justifying a major release.
And because the CLI is nowadays more of an afterthought, rather than a priority,
it was removed in the Log Detective v5.0.0 release.
See 5.0.0 Release notes
for more.
We plan on deploying v5 into production on Wednesday, Oct 14th, 2026.
Note that there might be some temporary outage.
New asynchronous API in Log Detective v5
One of the requirements stemming from our plans for Testing Farm integration
was to transition Log Detective server’s API to asynchronous.
Requests to /analyze now return 202 Accepted with a Location header
pointing to /tasks/{id} instead of immediate results.
Clients must then poll GET /tasks/{id} until the task status reaches done
to retrieve the final analysis payload from the result field.
The response payload has also been simplified to:
{"explanation":"Failure explanation.","no_issue_found":false,"snippets":[{"line_number":42,"source_file":"build.log","text":"Line obtained from the log by some extractor tool."}],"solution":"Optional experimental feature suggesting a possible fix."}
Clients can also supply an optional UUIDv4 id in request bodies for retries,
and enqueued tasks can be cancelled with DELETE /tasks/{id}.
We also removed the emoji feedback collection from the server. Originally, we
thought that this might be a good way of collecting feedback on the usefulness
of Log Detective’s analysis in GitLab MR comments. Users would upvote
� or downvote � the analysis, giving us important
stats, and indicating whether or not our service is useful and improving.
However, ever since this feature was in production (April 2025),
on almost 2,400 analyses across more than 1,500 distinct MRs,
we only collected 83 reactions (as of Oct 7th, 2026).
The feedback’s low volume and sparsity unfortunately led us to the conclusion
that this was a dead end. We will draw whatever insights we can from the data,
but starting with v5, your feedback will no longer be collected this way.
We are sorry this feature did not yield the results we hoped for, and we
sincerely thank everyone who left feedback, your input was truly appreciated.
Turning User-Annotated Logs into Agent Context
At the start of the initiative behind Log Detective, we tried collecting data
about some specific build failures and interesting log message interpretations.
We encouraged package maintainers to provide logs with their annotations
via our website.
The data was intended for fine-tuning the language model for
analyzing RPM build logs. Our first target was a thousand annotated logs.
As it turns out, this is far too small to provide tangible improvements.
By the time we could collect enough quality data for effective fine-tuning,
the progress in newer language models’ efficiency would easily overtake
any in-house specialized solution.
Unfortunately, this was the case, and the annotations sat unused on a disk
for months. We thought it would be wasteful to not utilize the work some
of our colleagues and users put into providing us with their know-how via
these log annotations.
The transition to agentic Log Detective mid-2026 provided us with
an opportunity. During the agent’s workflow, we could use a tool to
access the annotations and enrich the agent’s context.
So we turned the data into something similar to
a RAG,
or a database. The snippets (small verbatim log sections)
are turned into embedding vectors, searchable by semantic similarity.
The Log Detective agent during its workflow can choose some log snippet from
its input and search the database for the most similar annotated log snippets.
Each such annotated snippet is then associated with its meaning or
interpretation, the overall build failure reason, and proposed solution
(all provided by users during annotation). This information is then inserted
into the next iteration of the agent’s workflow, and can improve the agent’s
accuracy, especially in cases where the build failure is not so explicit or
obvious from logs themselves. So now, the logs you annotated, the work
you put in, is finally reflected in Log Detective’s responses! Thank you.
The third quarter of 2026 is over, and so in this post we’d like to highlight the top Fedora Quality contributors who helped us maintain the quality bar for Fedora during this time period. Fedora wouldn’t be a high-quality distribution without its community. Every single person who helped us detect and resolve issues, or verify that things work as expected, deserves our gratitude, thank you!
If you haven’t participated yet in testing Fedora, perhaps you’d like to give it a try? We gladly welcome everyone. Please look at our Fedora Quality homepage.
Testing proposed updates
When software packages are updated in Fedora (bringing bug fixes and new features), they are not released to end users immediately. They first go to the updates-testing repository, where they undergo automated testing, and also await manual feedback from human testers. This feedback can be provided through Bodhi, either by using its web interface or CLI tools, see instructions. Alerting package maintainers by posting a negative feedback with a problem description can stop the update from reaching general audience and causing issues to all our users. Testing proposed updates is a simple, yet vital process for keeping Fedora releases of high quality during their whole lifecycle. It is used both for already stable and in-development Fedora releases.
…and also 366 other testers who commented on less than 10 updates each, but submitted 777 comments combined!
1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.
Test days participation
Test Days are events which are partly focused on testing Changes planned for an upcoming Fedora release, but they also regularly test important areas of the Fedora distribution, like upgrades, internationalization, graphical drivers, desktop environments, kernel updates, and others. The upcoming and past events can be seen in our Testdays app.
Test period: Q3 2026 (2026-07-01 – 2026-09-30) Contributors: 67 Test cases executed: 598
Name
Test cases executed
tagoh
36
derekenz
28
ephmo
28
mcrha
23
pnemade
22
smjagtap
22
adriend
22
clnetbox
21
romeo-55
20
pschindl
19
toodz89
19
psklenar
17
modehnal
16
oholy
15
axelzenzu
14
pacorro2000
14
lruzicka
14
vcholasta
14
developer1
13
feborges
12
romangherta
12
vhumpa
12
jgrulich
12
mtadault
11
luya
9
geraldosimiao
9
bohdan_milar
7
lpavan
7
ersen
7
pyadav
7
jandemus
7
abdallahleandro
7
panayang
7
vlcekpavel93
6
nielsenb
6
imabug
6
tharadash
6
guiltydoggy
6
jgroman
6
kengou
5
kanru
5
rvykydal
5
…and also 25 other testers who executed less than 5 test cases each, but submitted 44 test results combined!
Dear testers, we're happy to announce Kiwi TCMS version 16.6!
IMPORTANT:
This is a minor version release which includes multiple security related updates,
improvements and bug fixes, new API methods and internal refactoring.
With the release of MacOS 27, Apple announced that they dropped support for Intel Macs and so I decided to repurpose my 2019 Intel Mac Mini that I had spec’d out with 10G Ethernet and 16G RAM. I was able to unlock the boot loader and load up Linux on it to turn it into a 10G SFP+ connected router.
Hardware-Defined Networking: I was previous running a Lenovo Mini PC with a 4 port 2.5G card where I could connect the WAN, LAN, VPN In, VPN Out to the router directly. The previous setup was technically more efficient as the bulk of the traffic was flowing in and out of the router.
Software-Defined Networking: In the new setup, the bulk of the traffic is also now flowing in and out of the switch as well as the router which is technically less efficient. The M4 Pro Mac Mini is still running the VPN In / Out solution that I had previously worked on and posted about before (including the proxy backup solution as well).
Now I have the Intel Mac Mini connected with a 10G SFP+ trunk port which has the 4 separate VLANs on the switch to connect and separate those 4 different networks working along side the ARM Mac Mini!
The 4 main functions and routing paths of the VLAN network are:
Client -> WiFi
WiFi -> VPN
VPN -> WAN
WAN -> Server
The USW PRO MAX switch is now fully connected with the following ports from the right:
cockpit-tls now limits the amount of concurrent connections to a sensible default of 500, and can be modified in cockpit.confWebService section with MaxConcurrentConnections.
Impact
A Denial of Service attack on cockpit-tls made in possible for unauthenticated remote clients to create detached threads which consume process resources, and degrade or deny service availability.
Affected systems
The affected versions are up to and including Cockpit 367. (cockpit <= 367)
We have improved our SSH keys modal to now include a file chooser with system navigation, recent history, and common locations to improve the user experience in finding the necessary files.
Machines: Security hardening of CLI usage [CVE-2026-92768] [CVE-2026-92747] [CVE-2026-92745]
Impact
An attacker with system access could access sensitive VM credentials, including plaintext passwords and RHSM tokens, by inspecting process command-line arguments during VM creation or installation.
Affected systems
The affected Cockpit Machines versions are up to and including Cockpit Machines 356. (cockpit-machines <= 356)
Files: Security hardening of CLI usage [CVE-2026-91202] [CVE-2026-91203] [CVE-2026-91205]
Impact
An attacker with system access could redirect file ownership to change arbitrary files, allowing the attacker to potentially read and write to unauthorized files.
Affected systems
The affected Cockpit Files versions of CVE-2026-91203, CVE-2026-91205 are up to and including Cockpit Files 44. (cockpit-files <= 44)
The affected Cockpit Files versions of CVE-2026-91202 are Cockpit Files 16 up to and including Cockpit Files 44. (cockpit-files >= 16, cockpit-files <= 44)
Après 12 ans, ma balance Withings a rendu l'âme. L'occasion idéale pour abandonner MyFitnessPal, auto-héberger la synchronisation de mes données de poids vers Garmin et automatiser le flux vers Strava via n8n.
A bit late with the weekly recap this week, possible due to lower energy
from getting my flu and covid boosters friday, but lets go...
Mass update/reboot
The mass update reboot cycle went pretty well. We also applied firmware to
all the machines that had updates, which always takes a while, but probibly
is worth it.
Database server upgrades
Also, as part of the outage on thursday to do the outage causing hosts updates
and reboots, we moved all our database servers over to postgresql 18, rhel10,
and the latest timescaledb (in the case of db-datanommer).
That also went reasonably well, and we shouldn't have to do that
again for a while.
Fedora 45 infrastructure freeze coming up
This coming tuesday is the start of the infrastructure freeze for fedora 45
final release.
Out next weekend
I'm out next friday through sunday, heading to seattle for a rust concert.
I'm planning on taking the train, so that should be fun, but there will
not really be a recap next weekend. :)
September 2026 brought another wave of organizations whose Kiwi TCMS instances
crossed the 1000-events mark for the first time. Below is a short, by no means
exhaustive, look at who they are and what they do.
Disclaimer: the information below was obtained via anonymous analytics and
represents only instances of Kiwi TCMS which crossed 1000 events during
September 2026. We've used publicly available data in order to identify these
organizations. Note that we don't keep track of individuals or IP addresses!
Austria
Scientific Games - lottery systems, digital gaming and sports betting technology
Humans are bad at writing secure code, and GNOME developers are no exception. GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code when using unsafe languages like C, C++, or Vala: it’s just too hard for even experienced developers to do properly.
The above paragraph is taken from the abstracts of my GUADEC 2024 and 2025 talks. At the time, I thought failure was inevitable: we humans were so bad at writing software that we had no chance to do it properly, and I certainly would not have trusted an AI to do better than a human. But the landscape today is completely different than last year. AI has improved considerably, and offers a magic fairy wand solution to this problem: we can now simply ask a language model to look for vulnerabilities in our software. They are quite good at this.
There is zero hope of maintaining quality software in 2026 without AI vulnerability scanning. Any claims to the contrary are unserious and delusional. The tremendous quantity of bugs found in our best-maintained projects, like GLib and fwupd, should speak for itself. Failure to scan our projects is an unfair disservice to our users. If we don’t find the vulnerabilities by scanning projects ourselves, attackers certainly will, because the Linux user base has increased to the point that Linux users are finally numerous enough to be worth targeting. Meanwhile, AI has made it easier than ever to build working exploits, which was previously unheard of.
Already resolved all the detectable vulnerabilities? Then ask the AI to look for non-security bugs as well, to further improve quality. GNOME code is generally much better than it used to be, but there remains considerable room for improvement. For the first time in history, we now have the opportunity to improve software quality to a degree that was never realistic before.
Have you heard that most AI bug reports are “slop?” Not so in 2026. That was true for most of 2025, but the quality of AI-generated vulnerability reports has drastically improved. That is not to say that we no longer have problems with bad vulnerability reports, but in general, nowadays most of them are pretty good. (Daniel Stenberg reports the same pattern for curl.)
AI-generated vulnerability reports have nevertheless introduced many undesirable impacts on GNOME maintainers. They are usually annoyingly verbose and unnecessarily detailed. They often exaggerate the severity of the problem, or make misleading or irrelevant claims. They are occasionally incorrect. Sometimes they include outright fabricated data, such as fake stack traces (which is not the norm, but sadly also not uncommon). A good human reviewer will notice and resolve most of the above problems before creating a bug report on your issue tracker, but often problems are reported by inexperienced humans who do not actually know what they are looking at and simply copy/paste everything blindly. Even when the generated issue report is good and avoids all of the above problems (which is rare), good vulnerability reports in sufficiently high quantity can still overwhelm volunteer maintainers. And even if reporters submit a merge request to resolve the problem so maintainers don’t have to (which is also rare), reviewing those merge requests is itself more unwelcome work for overworked maintainers.
That all is to say: I understand the pain caused by the current wave of AI-generated issue reports. Nevertheless, they are essential and unavoidable. We have to learn to accept and deal with them, not stick our heads in the sand and ignore them.
Some GNOME maintainers have adopted a policy prohibiting AI-generated content in issue reports. Do not do this. Nowadays, the overwhelming majority of vulnerability reports are AI-generated. Projects that choose to ban AI-generated content in issue reports might as well ban all vulnerability reports; the effect will be approximately the same.
Projects that continue to prohibit AI-generated vulnerability reports are no longer suitable dependencies for GNOME, and should be developed someplace other than GNOME GitLab.
We don’t have to tolerate bad issue reports, but AI use alone should not be disqualifying.
When I complain that maintainers should allow AI-generated vulnerability reports, the most common counterargument is that humans should read the AI’s report, understand it, and rewrite the entire thing to remove all AI-generated content. Some bug reporters actually voluntarily do this, but this is rare.
Vulnerability reporting is a public service, not an obligation. If you ask a reporter to do any amount of extra work, they might be willing to do so, but it’s much more likely that they will either stop looking at your project and move on to something else, or continue looking at your project and publish the vulnerability reports someplace other than your issue tracker.
Rewriting issue reports also does not scale. Let’s say you use AI to find 100 security bugs in a GNOME project, a number consistent with the results of actual scans (read on). Would you really spend months rewriting those bug reports before submitting them to upstream? Validating the AI’s claims, upstreaming the issue reports, and submitting merge requests is already a lot of work. Not many people would be willing to additionally rewrite all the issue reports. That’s more work than everything else combined, and is unrealistic.
Even with just a small number of bugs, I would hesitate to spend much time rewriting an issue report because I have many other tasks I would rather spend my time on. At best, I might prepare a quick summary, but it won’t be as useful as a full report.
The CVE Wave Hits GNOME
The current wave of vulnerability reports is reflected in GNOME’s CVE issuance trends:
Year
GNOME CVEs
GNOME CVEs Excluding GIMP, Gegl, libxml2, and libxslt
2021
21
14
2022
14
6
2023
13
4
2024
37
28
2025
97
49
2026 Year-to-date (2026-09-30)
141
74
2026 Normalized
188 (141 * 4 / 3)
99 (74 * 4 / 3)
The trend here should be pretty clear. Until recently, not many people were reporting vulnerabilities in GNOME. That has changed. We are currently dealing with an order of magnitude more CVEs than just 3 years ago. AI is not the only reason for this; GNOME maintainers have also gotten a little better at flagging issues so that I add them to security tracking. But AI is the primary cause for the increase.
(A few technical notes on this table. CVEs are classified by the year the issue was reported to GNOME, not by the year in the CVE identifier, so e.g. many CVE-2026 issues are counted in 2025. Vulnerabilities reported in 2026 which do not yet have CVEs are not counted, so you can think of the data as being accurate through roughly September 1; multiply the 2026 numbers by 4/3 to make them comparable to the prior years. I count only issues reported to GNOME Security, so any unreported CVEs do not count.)
Although there are still 3 months left in 2026, we will never have data for the rest of the year because I have ended security tracking for new issue reports and nobody else has volunteered to do that work. These CVEs exist only because I request them myself, so I expect the number of CVEs to drastically decrease going forward.
CVEs are reported against the year they appeared in a WebKitGTK security advisory, not the year in the CVE ID. The large increase in 2026 is entirely due to AI analysis of Skia and ANGLE. WebKit bundles these libraries because they are not designed to be installed as system libraries, so their vulnerabilities should be counted the same as vulnerabilities in WebKit’s own code. Excluding Skia and ANGLE, there are actually only 21 other WebKitGTK CVEs so far this year, a significant decrease, but excluding CVEs in bundled code would not be fair.
There has actually been a very large increase in WebKit security fixes this year, but this has not resulted in any increase in CVEs. Apple generally creates CVEs for flaws found by external researchers, not often for flaws found by WebKit developers, so the increase in security fixes is not reflected in the total number of CVEs. Only a small fraction of WebKit vulnerabilities receive CVEs.
I had not previously noticed that the count of WebKitGTK CVEs had, until 2026, been decreasing over the past decade. I am not sure why. I also do not know how to explain the low number in 2016.
Announcing the GNOME Bug Bounty Program and Announcing the End of the GNOME Bug Bounty Program
My blog post to-do list says that I need to write a blog post announcing the creation of the GNOME Bug Bounty Program on the YesWeHack platform. Oops, too late. It’s already closed. (Once a task enters my to-do list, it can be a very long time before I get around to doing it.)
The GNOME Bug Bounty Program was generously sponsored by the Sovereign Tech Resilience program of Germany’s Sovereign Tech Agency. I’m not sure precisely when it opened, but the first vulnerability was reported on June 27, 2024, so it would have been sometime shortly before then. We accepted issue reports only for GLib, glib-networking, and libsoup, because GNOME had never operated a bug bounty program before and we did not know what to expect. Starting small had — naively — seemed like a prudent way to avoid a large quantity of issue reports. I had wanted to expand the program to cover all of GNOME, but this failed due to the overwhelming deluge in issues reported against GLib and libsoup.
I requested that the bug bounty program end because I was overwhelmed with incoming AI-generated issue reports. The final issue was reported on February 23, 2026. Here are the results:
Year
Reports Submitted
Reports Accepted
2024
26
14
2025
150
33
2026
122
24
Total
298
71
Those numbers for 2026 reflect less than two months’ worth of issue reports, so you can see why it was no longer sustainable.
After the program closed, our work was not done: there was a long backlog of reports to work though. We just last month caught up with accepting the last of the issues reported back in February, and the last bounty was finally awarded earlier today! Even with YesWeHack’s professional triagers analyzing the issue reports before I reviewed them, keeping up with such a large number of vulnerabilities was not easy for me.
At this point, all reports not accepted have been rejected. The program awarded €183,900 in bounties for 71 vulnerabilities: 45 in libsoup, 23 in GLib, and 3 in glib-networking. Award amounts varied from €500 (16 awards) to €7,500 (2 awards). The arithmetic mean award was €2,662.99.
Bug bounty programs are an exception to the rule that most AI-generated vulnerability reports are good. You can see the number of reports accepted is a small fraction of the number of reports submitted. Excluding 30 reports closed as duplicates, that leaves 197 reports rejected. Turns out, people will submit bad reports when financially incentivized to do so. The low percentage of accepted reports even understates the problem, because many of the accepted reports were actually not very good! Many accepted reports did successfully identify valid security problems (in fact, many of the rejected reports successfully identified valid security problems!), but required many rounds of revision and corrections.
Suffice to say, I have reviewed a lot of really bad AI-generated vulnerability reports. But the reports we received via the discontinued bug bounty program are not comparable to the reports received via regular GNOME issue trackers or the security bug report form. We do still occasionally receive bad vulnerability reports, but not often and not many, so it’s not a big problem anymore. When people submit AI-generated reports without hope of a financial award, those reports are generally much better.
Lessons from the Bug Bounty Program
Closing the bug bounty program because it found too many vulnerabilities is not a particularly pleasant result. That said, it was still a partial success in that it uncovered lots of bugs in libsoup and GLib.
I had hypothesized that libsoup was probably not very secure, but I never imagined just how many vulnerabilities would be discovered. To reduce the quantity of incoming issue reports and better reflect actual risk to GNOME users, I eventually removed all denial of service bugs from program scope, and then later removed SoupServer from the scope due to too many request smuggling vulnerabilities, which are HTTP request parsing bugs that pose no threat to GNOME users. Even with those changes, the libsoup vulnerability reports kept coming until I gave up. The silver lining is that libsoup is now relatively much more secure than before. Other bug reporters have been submitting AI-generated bug reports using the normal libsoup issue tracker, so fortunately the improvements to libsoup will continue despite an end to the financial awards.
I had hypothesized that GLib would be much better than libsoup. I’m not sure whether I was correct. Evaluating the severity of GLib flaws is much harder than for libsoup, since GLib vulnerability reports are generally hypothetical in nature: usually some proof of concept program calls a GLib API using valid but improbable values, then something bad happens.
A large portion of the GLib bugs were integer overflow flaws, which generally result in buffer overflow. I am now more scared of integer overflow than anything else. It’s likely that most software projects have many integer overflow problems. Fortunately, we should be able to catch most such problems by adjusting the compiler flags we use. In particular, -Wconversion or -Wint-conversion and -Wsign-compare should help here. Some GNOME projects already use -Wsign-compare, but I suspect most do not. I think few or no GNOME projects use -Wconversion or -Wint-conversion.
Resuming the bug bounty program would only be possible under substantially different conditions. What we were doing was not working well. To resume, we would need to limit the scope to projects that regularly perform their own AI vulnerability scans. We would also most likely want to pay only for functional exploits, rather than for all vulnerabilities. GNOME code is currently not good enough to continue paying for every vulnerability, and it no longer makes sense to pay bounties for issues that can be found by AI scanners.
Red Hat Scans GLib
Red Hat has contracted with AISLE Research to perform AI vulnerability scans of various GNOME projects. We received a large quantity of findings, and are only just now beginning to individually validate and report our findings to upstream. GLib is by far the hardest hit project, which I was not expecting, accounting for more than 40% of our total findings. I’m not certain why, but perhaps this is because GLib provides so many public APIs. Data passed to public APIs is potentially untrusted, so the attack surface is considerable.
Red Hat’s scan of GLib found 118 vulnerabilities. Or at least, it claimed to. However, due to the way we ran the scans, several of these are actually unnecessary duplicates of each other, which we have not fully deduplicated yet, so the number I report is not entirely trustworthy. Moreover, 46 of these “vulnerabilities” are bugs in gobject-introspection, mostly in the typelib support, which is evidently not very robust. A typelib controls how your program calls libraries; it is effectively calling convention, so it must inherently be fully trusted: a malicious typelib would be able to induce vulnerabilities even without any bugs! I would expect an AI ought to have been able to figure that out, but apparently not. These bugs are still real problems that we ought to fix, but all maintainers agree they are not security vulnerabilities, so let’s count all of them as false positives. That alone creates a 40% false positive rate. Ouch.
I don’t have more stats to share here because we are not yet done working through the issue reports. That said, I am quite pleased with the results thus far. Substantially all of the reports are high-quality. The false positive vulnerability reports are almost all due to one particular misunderstanding and can be treated as good quality non-security bug reports, which are still valuable. Expect many forthcoming CVE assignments for the other findings.
It’s rare for Linux vendors to proactively look for software vulnerabilities, rather than waiting for security researchers to report them. This was a successful experiment in proactively seeking out problems.
Humans Still Useful
In addition to the bug bounty program, the Sovereign Tech Resilience program also sponsored a security audit for GNOME, performed by Codean Labs. This resulted in many findings in various GNOME projects. Most notably, the scope of the audit extended to Flatpak and xdg-desktop-portal, resulting in criticalfindings.
Most of these issues could have been detected via AI scans, but I am not confident that AIs would have been able to discover the most important findings, like the two Flatpak sandbox escapes that I linked to above. Accordingly, I do not recommend relying on AI alone.
Humanity Still Desired
Although I like AI-generated issue reports, I particularly do not appreciate when I wind up interacting with a robot rather than with a human. It’s pretty obvious when your issue tracker or code review comments are written by an AI. Consider whether outsourcing your writing and your thinking to a language model is truly wise for your public image.
We even have one experienced GNOME developer who is obviously using AI to write all of his posts on GitLab. I am unsure whether he is copy/pasting all of his responses from an AI, or whether he is just a bot now. I especially do not understand the value of this.
Here is a soft proposal, intended only as a starting point for discussion and not as a serious proposal, for what my preferred AI usage policy might look like:
Newer developers should exercise caution when using AI to write code. Your priority should be learning, and I wonder how much you are really learning when relying on the AI to do work for you.
Do not use AI to write code comments. Currents AIs are terrible at writing comments. Most comments written by AIs should be deleted. If a comment is truly necessary, then I’d like to see it written in your own words. Presumably AIs will get better at this eventually, but as of 2026, human judgment is still required here.
Do not use AI to write commit messages. AIs are actually probably better than humans at writing commit messages, but I would still rather hear your own thoughts on the code you are submitting.
Certainly do not post AI-generated comments on an issue tracker or merge request as if they are your own. You’re not fooling anybody.
Maintain Perspective
Are you scared by the large numbers of recently-discovered vulnerabilities? There is no need to panic. Security bugs are just bugs, and they’re not necessarily more important than other bugs. Occasionally they are emergencies, but far more often they are boring and unexceptional. Security vulnerabilities are not even the biggest digital security threats that users face: those are surely phishing and trojans, with software security bugs a distant third place. No amount of CVE fixing will protect you from those more likely threats.
I don’t want to downplay the severity of security issues either. In fact, evaluating severity is hard. I quite often decide that a bug is not a big deal, only to be proven incorrect. Ideally, we would fix as many security issues as possible, and sooner rather than later. Lifetime issues and out of bounds writes are especially important to fix. Two years ago, I claimed that memory safety vulnerabilities were becoming less threatening, a claim that did not age well: that is surely no longer true due to the drastically increased accessibility of AI exploit generation.
Nonetheless, volunteer maintainers should not feel obligated to fix security issues or treat them as higher-priority than other bug reports. It’s certainly good to fix problems when possible, but my request is only that you do not prohibit issue reports, not that you attempt to personally resolve every security problem yourself. When I add due dates to vulnerability reports, that represents only a disclosure deadline — because issue reports should not stay confidential indefinitely — not an expectation that you fix the issue by that date. Resolving security problems in projects used by big tech companies that depend on your software without contributing back is basically free labor for said companies, and only you can decide whether that’s how you want to spend your volunteer time.
Rust
Yes, even projects written in memory safe languages like Rust still need to allow AI-generated vulnerability reports. Rust will indeed eliminate most memory safety issues (except in unsafe blocks), and you can reasonably expect a Rust project to have an order of magnitude fewer vulnerabilities than a comparable project written in C or C++ or Vala. This is amazing, but not all vulnerabilities are memory safety issues, so this is not an excuse to avoid scanning for flaws.
Although Rust mostly eliminates memory safety risk, any use of Cargo to download dependencies dramatically increases supply chain security risk. The risk of bundling a trojanized dependency arguably — I would even say probably — outweighs the benefit of eliminating memory safety flaws. This problem is inherent to any programming language package manager. Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.
To Be Continued…
I have exhausted my thoughts on AI vulnerability reports, but there is still much to discuss regarding software quality. Next time, I will discuss additional strategies to improve GNOME quality without significantly relying on AI.
As previously announced, I have discontinued my tracking of GNOME security issues. Nobody else has volunteered to continue that work, so it has concluded (except for issues reported during September 2026, which I will keep an eye on until the end of this month).
Maintainers, I encourage you to request your own CVEs by writing to Red Hat Product Security. Red Hat is an ideal CNA (CVE Numbering Authority) to use for GNOME CVEs because you will receive timely responses. Ignore Red Hat’s suggestions to encrypt your mail using GPG, and use the following email template:
Hi, I request a CVE for:
Summary:
Requirements to exploit:
Component affected:
Version affected: All versions <-- change this if needed
Patch available: Yes/No
Version fixed (if any already):
Upstream coordination: See issue report (below)
CVSS (optional):
Impact (optional):
Embargo: No
Acknowledgment:
Steps to reproduce if available: see issue report
Mitigation if available: <-- it's OK to write "None"
Original report:
Request a CVE after making your issue report public. It’s possible to reserve a CVE in advance, but this requires twice as many steps, so I recommend making it public first, then request a CVE second.
GNOME and Fedora maintainers should feel free to get in touch with me if you have questions.
Very few companies are ever listed in the official Gazette.
After that painful lesson, as they progress towards being in a position
to run the UK Government, wouldn't you expect them to improve their
procedures and run their party headquarters competently?
It looks like
Sarah Cooper-Lesadd
is right. They admit despite having one of the most serious legal
documents, a [redacted], served on their party headquarters,
they have no idea where it went:
Fortunately, the process server provide video evidence so I can prove it
was served correctly and the incompetence is not on my side.
Look at the cost. Their lawyers,
Aston Bond, have invoiced over £25,000 before the first hearing.
Most of that is for investigating what went wrong inside their own
organisation and how the dispute was
leaked by the MouseInTheCourt before the [redacted] ever arrived on
the doorstep of party HQ.
Why is
Nigel Farage so so afraid of a candidate who only got sixteen votes?
As
Reform UK tries to [redacted], they have complained
to the court that [redacted] other failed candidates,
Reform UK defectors, independent contractors and small business owners
how to [redacted].
If they block more people [redacted]
It is not my intention to publish the forms unless the conduct and
behaviour of these people forces me to do so.
Judgment: VMS Enterprises Ltd vs The Brexit Party Ltd ([2021] SC GLA 49)
The Brexit Party Ltd became
Reform UK Party Ltd, company number 11694875. This
subsequently got merged into Reform 2025 Ltd to become a
different Reform UK Party Limited company no. 16260766. An
inconvenient consequence of this name change and merger is that people
searching for judgments against the new company number 16260766 don't
see the history of the old company name and company number.
The full judgment is available here for download as an Acrobat document:
The political party, formerly led by Nigel Farage as the Brexit Party during the 2019 general election, faces a hearing in the High Court in London as early as September. Victor Shields, director of VMS Enterprises, was forced to take the party – since rebranded and led by Richard Tice – to court over the bill from the 2019 general election. Despite Glasgow Sheriff Court agreeing the party should pay up, it has consistently refused to answer letters or pay the sum owed to the businessman, forcing him to take further legal action in England. It is understood a winding up petition was served on the political party last week, with a hearing set for September 7 or soon thereafter. Reform UK has consistently rejected the claim, now worth more than £26,000 after interest and before court expenses are taken into account. A winding up order, if granted by the court, would see the party face liquidation proceedings to pay the outstanding amount and could include an investigation into director conduct. The initial Scottish court case arose after a dispute between the party and VMS Enterprises around payment for election billboards in London during the general election campaign. The court stated the party was liable for the bill for advertising services after some invoices were paid by Brexit Party staff and others were not questioned. Several invoices had gone unpaid amid claims a volunteer did not have the authority to charge the party for the billboards. However, the court stated the failure to question the payment of invoices incurred by candidates meant the party was liable for the full costs. Speaking to The Scotsman last year, Mr Shields attacked Reform UK’s “hypocrisy” in failing to pay. He said: “I was quite happy to keep quiet after the judgment because I assumed they would respect the Scottish courts and duly pay us. "They don't care. They feel they are above the law. "Richard Tice is positioning himself to the right of Boris [Johnson] and trying to capture the Conservative voters, Scottish voters too and here we are being forced to go to English courts, for me being forced to spend further money, to try and recover a debt that is legally due to us." The court case heard witnesses describe the organisation of the Brexit Party, then led by former UKIP leader Nigel Farage, as "shambolic" by a party official as it struggled to cope with its popularity and decision to pull hundreds of candidates from the ballot paper ahead of polling day. Witnesses told the court the party’s organisational structure "visibly started to fall apart", was "very unprofessional" and "beyond chaotic" ahead of the 2019 election. Reform UK’s latest accounts state that in 2020 it received nearly £3 million in donations, with a further £17m in 2019. Reform UK has been contacted for comment by The Scotsman.
Eighteen months after the judgment, almost two years after the judicial procedure
began, in December 2022,
VMS Enterprises Ltd used the High Court insolvency procedure to publish
an insolvency notice for Reform UK Party Limited.
As a consequence, a listing was placed in the official Gazette with their
old company number 11694875 and the High Court case number CR-2022-003973.
Diagram demonstrating evolution of the Reform UK companies
Searching for information about the names and company numbers is tedious
and time consuming. I created a colour-coded diagram so people can see and
understand the relationship between the companies in the history of
Reform UK at a glance.
Looking through the filing history of each company, you can see many minor
changes, including some name changes. I put the filing history for both
companies side-by-side:
Drilling down on the name changes, it is fascinating to put the two
forms side-by-side like this:
Here is the full diagram I created to help people understanding the
judgment and insolvency court history of
Reform UK and its leaders at a glance:
Direct links to search the Gazette for old company number
11694875
and for the new company number
16260766.
People who have a legitimate claim against any company
are encouraged to contact their solicitor for advice
and share their contact details with other creditors to resolve
the dispute more expediently. See my previous blog about how to
join a creditors petition in the UK.
Reform UK is the only major political party in the
UK that is also registered as a company at Companies House.
Consequently, each year, they must file a set of accounts, with an
auditor's report, at Companies House. The deadline was today,
30 September 2026. Why did they file the accounts at the very last
minute and not at the same time they filed with the Electoral
Commission?
As explained in
my previous blog on the subject, the reports given to Companies House
are slightly different from the reports given to the Electoral Commission.
The Electoral Commission is trying to show the impact of money on
democracy. The Companies House report aims to give members, investors,
trading partners and employees an image of the organisation's strength
or weakness.
The document uploaded to the Electoral Commission in June is a
text-searchable PDF. The PDF uploaded to Companies House is not
text-searchable. However, Companies House also has another copy
in iXBRL, which is an XHTML file that is text-searchable in a web
browser.
At a glance, we can see the numbers are not exactly the same.
For example, the membership revenue in the report to the
Electoral Commission appears to be a bit higher because they used
to collect the money through a different company and then they
subsequently merged the two companies during the 2025 reporting
year.
Like the report submitted to the Electoral Commission, the report
submitted to Companies House does not mention the potential impact
of the new, backdated restrictions on donations from overseas electors.
If those restrictions are implemented soon, they will have a very
severe impact on
Reform UK. It seems odd to me they can completely omit that
from the statement about the company being a going concern
for the next 12 months.
One of the very significant differences in the Companies House
report submitted today is on the very last page. It is the
declaration about how they merged the two former companies and
who really has control over the company, which is acting as a
political party but is really a business:
19. Related party transactions
On 19 February 2025, the company acquired the entire issued share capital of Reform 2025 Ltd for consideration of £15.
...
20. Controlling party
The company is limited by guarantee and has no share capital. The company has two members, who have equal voting rights. Neither member has individual control of the company and, accordingly, there is no ultimate controlling party.
...
Legal form of entity and country of incorporation
...
The company is limited by guarantee and has no share capital. The liability of each member is limited to £1, being the amount that each member undertakes to contribute to the assets of the company in the event of its winding up. There were two members at the year end.
Companies limited by guarantee in the
UK are a special type of company that is normally used for non-profits
and charities. In some non-profits, like sporting clubs, every member
is really a member of the company and invited to the annual general meeting.
The accounts that
Reform UK has just filed show us they have a two-tier membership structure,
similar to the scandal of the
FSFE misfits.
People who "join"
Reform UK and pay £25 per year are not really members like
Nigel Farage and
Zia Yusuf are members in the accounts.
In
UK law, the real members,
Nigel Farage and
Zia Yusuf, can choose to change it into a normal shareholder company
at any time they want and then they can sell the shares or pass them to
their children, as long as the articles of association permit that.
In June 2025,
Zia Yusuf resigned from Reform UK and came back two days later.
The accounts show us that he resigned from his position on the board
but they do not tell us if he transferred his position as one of the
two controlling members to somebody else.
Reform UK claims to have more members than any other political
party in the
UK. These accounts tell us their company only has two members,
making it one of the smallest political parties at the same time
as being one of the biggest.
If the members accept this two-tier structure, does that mean it
really is a
cult, as we were
told by Rupert Lowe?
When they changed the structure, they told people they were
making it more democratic. What they really did is they reduced their
risk. If it fails, they only lose their guarantee, which is £1
each. If it succeeds, these two people can choose to pivot back to a
shareholder company form, issue shares and sell them on the stock market.
The other thing they did through this reoganisation is obfuscating the
history of disputes and judgments against the former company. It looks
like at least one law suit is still progressing against the old company
and it is not clear if the new company structure will be obliged to pay
for it if they lose.
The UK permits directors, company secretaries and shareholders
to be nominees, in other words, proxies contracted to obey the
person who really pays them to perform that role. While
Nigel Farage and
Zia Yusuf are listed publicly as the members who founded the new entity
in February 2025, there is no obligation for them to publicly identify
any transfers of these memberships to other people. The only thing we
can deduce from the report is that there are currently two members,
the same number of members they had when they created the entity
but not necessarily the same two people.
In the sentencing of the late
Cardinal George Pell, it was his defence lawyer
Robert Richter KC who argued the Cardinal should receive a
lighter punishment because it was a "plain vanilla" case of abuse.
In fact, when somebody in such a senior position of trust commits
an offence of that nature, it is a lifelong case of psychological torture
for the victims. That is what makes institutional abuse, such as the
abuse by jurists and the
abuse by the Catholic Church so much worse than other types of
abuse.
A while ago at work, I was assigned a Lenovo ThinkPad T450. Recently, its
original 128GB SSD running Debian Testing suffered a permanent hardware
failure.
Hardware Failure and Data Recovery Strategy
The laptop's SSD began showing signs of wear before finally freezing mid-task
while I was running Android Studio and an active collaborative project.
Subsequent attempts to boot or reinstall an operating system failed
completely, as the drive had locked itself into a permanent read-only state.
Fortunately, all development projects were properly mirrored in remote Git
repositories, and critical local documents were preserved on secondary machines
via incremental backups managed with rsync (a tool I will cover in a future
publication).
Storage Upgrade and Hardware Maintenance
To restore the ThinkPad T450, I originally planned to acquire a 256GB Samsung
850 Pro. However, due to component price spikes driven by AI industry demand, I
opted for a budget-friendly 240GB Crucial BX500 instead. On that same order, I
also picked up a uni-ball Jetstream Prime Twist pen and a Kuru Toga Metal
mechanical pencil (my first mechanical pencil in 17 years).
To my surprise, when the package arrived, the vendor had shipped a 480GB
SanDisk SSD Plus instead of the 240GB drive—double the storage capacity for the
same tier.
Received a 480GB SanDisk SSD Plus instead of the ordered 240GB drive.
I removed the bottom chassis cover of the T450, extracted the defective SSD,
and mounted the new 480GB drive.
Taylor internals after removing a few screws and snapping off the bottom.
Then removed the old SSD from the enclosure.
Unboxed the new SSD.
My new SSD.
The new SSD is ready to be installed on Taylor.
After reassembling the chassis, I booted into the system BIOS to confirm that
the new disk was properly recognized.
The new SSD is successfully recognized and listed on the boot menu.
Installation via Fedora Everything Netinstall
To maintain a lean, bloat-free system, I created installation media using the
Fedora Everything Netinstall ISO (Release 44, x86_64) available from the
official Fedora repository:
Unlike the standard Live Workstation media, the Netinstall image allows
explicit selection of individual package groups and components. Once options
are finalized in the Anaconda installer, all necessary packages are fetched
directly from the upstream Fedora mirrors. This ensures that every installed
binary is completely up to date from minute one.
Taylor booting up from the installation media that contains the Fedora
Everything Netinstall ISO for release 44, for x86_64 devices.
During the installation I made use of my Motorola ThinkPhone to share its Wi-Fi
connection to Taylor via a Wired USB Tethering network:
This is a good example of how useful a USB Wired Network can be in some
scenarios.
Once download and deployment completed, Anaconda performed a clean reboot into
the fresh installation.
Installation completed and Taylor is ready to reboot.
This is Taylor's GRUB2 menu with the latest Linux kernel available for Fedora
Linux 44 already installed:
Taylor booting up to Linux 7.2.7-200.
Upon selecting the kernel, I was prompted by the cryptsetup password manager to
decrypt the disk:
Time to insert the passphrase.
This is Taylor's System Information under Fedora Linux 44 (Workstation
Edition) with GNOME Shell as Desktop Environment.
Minimal System Metrics and Metrics Overview
Below is a breakdown of metrics, repository lists, and package selections for
this minimal Fedora 44 GNOME Shell Workstation setup:
Installation Date and Time
There are many ways to confirm when the Fedora installation started, when some
filesystems or partitions were created, and when the installation process was
completed with success.
One possible way is by inspecting the Anaconda Installer Logs. Fedora's
installer, Anaconda, copies its logs over to the target system upon a
successful installation. You can check the creation (birth) time of the primary
installation log or kickstart configuration file:
Another way is by checking the Root Filesystem Creation Date. Just like on
Debian, the underlying filesystem's birth time can tell you when it was
initialized:
During the installation I selected the Fedora Workstation Product, which is a
set of different Fedora package groups that guarantee that by the end of the
installation process you will have the minimal selection of packages that will
provide the Workstation experience intended by the Fedora development team.
This command lists all the repositories configured but disabled on the system:
porfirio@taylor:~$sudodnfrepolist--disabled
This command lists all the repositories configured on the system:
porfirio@taylor:~$dnfrepolist--all
List of the installed packages
I wanted to get a copy of all the installed packages just for reference. To get
the list of the packages installed and the order in which these packages were
installed, I used the following command:
With the base installation complete, the ThinkPad T450 is fully operational
with an up-to-date, non-bloated Linux workstation environment built on top of a
reliable upstream system architecture.
Version 8.6.0 Release Candidate 2 has been released. It's now entering the stabilisation phase for the developers, and the test phase for the users.
RPMs are available in the php:remi-8.6 stream for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, CentOS, Alma, Rocky...) and as Software Collection in the remi-safe repository (or remi for Fedora)
⚠️ The repository provides development versions which are not suitable for production usage.
The Fedora QA team invites you to participate in the Anaconda F45 features Test Week, which is running now through October 2, 2026. There is still time to jump in this week and help us shape the Fedora 45 installer before it ships.
What’s New in the Anaconda F45 Installer
Fedora 45 brings three significant changes to how you install the system. Each one is ready for real-world testing – and better testing means a better installer.
WebUI for Atomic Desktops – The modern web-based installer now covers the Atomic Desktops (Silverblue, Kinoite, and the Cosmic/Sway/Budgie Atomic variants). See the Change page.
Remote WebUI – You can now drive an installation from another device entirely, straight from a browser. See the Change page.
Stratis support – The WebUI can now configure Stratis storage. See the Change page and the introduction on Fedora Magazine.
How to Participate
Requirements
A virtual machine or a spare bare-metal box – not a production machine and not one with data you care about.
On September 19, 2026, the Fedora Project supported the conduct of Software Freedom Day Bukidnon 2026. The event took place at the Northern Bukidnon State College, Manolo Fortich, Philippines.
Now in its second run, Software Freedom Day Bukidnon gathered students, professionals, educators, and community members to explore how Free and Open Source Software can empower innovation, digital inclusion, and impact their daily lives, primarily in the province of Bukidnon, Philippines. Despite the challenges like power outage, the event was a massive success, demonstrating the local community’s resilience and passion for open technology.
Event Highlights
The event features an impressive speaker lineup, with presentations spanning foundational Open Source principles and cutting-edge technology trends.
Paul Harriet Asiñero while presenting Hello Fedora
Walt Miner while presenting Introduction to Automotive Grade Linux
Arjay Sitoy while presenting Local LLMs: My 8GB VRAM vs the World
Romar Mayer Micabalo while presenting Harnessing Krita For Fun and Profit
Rafael Tibudan while presenting Building a Second Brain: Turning Information into Leverage
Wei Lee while presenting Orchestration Still Matters: Apache Airflow in the Age of AI
Jay Ginete while presenting 5 Cool Open Source Tools to Pimp Out Your Windows CLI
Roger Madjos while presenting Practical Agentic Coding with OpenCode
Linux and Open Systems
Hello Fedora by Paul Harriet Asiñero – This session introduced attendees to Fedora Linux, highlighting its pivotal role in driving Open Source innovation. Participants explored the power, robust security, and exceptional flexibility that make it one of the world’s premier Open Source operating systems.
Introduction to Automotive Grade Linux by Walt Miner – Attendees received an exciting look at how Open Source technology has moved beyond PCs and servers, driving the software systems that power modern smart vehicles.
Art and the Developer Workflow
Harnessing Krita For Fun and Profit by Romar Mayer Micabalo – Proving that Open Source is just as crucial for creatives as it is for developers, this talk walked attendees through building a career or hobby using Krita, a premier Open Source digital painting tool.
5 Cool Open Source Tools to Pimp Out Your Windows CLI by Jay Ginete – A practical guide for developers stuck on proprietary systems, showing how to upgrade a boring terminal into an Open Source-powered developer powerhouse.
The AI and Data Pipeline
Local LLMs: My 8GB VRAM vs the World by Arjay Sitoy – In a highly relevant, budget-conscious session, this talk demonstrated how developers can break free from corporate API reliance by running powerful Large Language Models locally on standard consumer hardware.
Practical Agentic Coding with OpenCode by Roger Madjos – Shifting from consumption to creation, this session showed developers how to leverage Open Source AI agents to actively write and debug code. Attendees walked away with a practical blueprint for turning agentic coding into a reliable, secure, and repeatable development workflow that delivers value faster without compromising quality.
Building a Second Brain: Turning Information into Leverage by Rafael Tibudan – Explored how to use knowledge management, AI, and automation to build a digital “second brain.” The session shared simple, scalable strategies to transform past code bugs, research notes, and AI conversations into a personal knowledge base.
Orchestration Still Matters: Apache Airflow in the Age of AI by Wei Lee – Attendees got a deep dive into the backend infrastructure powering modern technology. The talk drove home a crucial point: even as artificial intelligence dominates the headlines, leveraging Apache Airflow to control and orchestrate the data pipelines and workflows powering AI applications remains absolutely vital to AI success.
Page Follow Bingo Game and Raffle Draw
In addition to the engaging sessions, the event featured a Page Follow Bingo Game and an exciting raffle for all attendees. The Bingo game was designed to boost engagement for our event sponsors and partners by encouraging participants to follow their official pages, with the first five to complete the task being crowned winners. The event wrapped up with a raffle draw featuring an array of prizes generously contributed by our sponsors. The raffle was conducted using pyraffle, an Open Source raffle draw software executed within a notebook environment.
Final Thoughts
Despite the challenges, Software Freedom Day Bukidnon 2026 was a resounding success! An impactful movement like this cannot happen in isolation. As we look back on the success of this year’s event, our deepest gratitude goes out to the incredible individuals and organizations who helped bring this vision to life.
Event Sponsors and Partners
Software Freedom Day Bukidnon 2026 Event Partners and Sponsors
This event was made possible through the generous support of our partners and sponsors. In addition to the Fedora Project, we would like to extend our sincere gratitude to the following organizations:
Aside from the participating organizations, we would like to express our gratitude to an anonymous donor for providing financial support for the event.
Speakers
Awarding of tokens for the Speakers
Thank you for sharing your time, passion, and unparalleled expertise. You gave our community tangible frameworks to work with, sparking ideas that will undoubtedly fuel local tech innovation for months to come.
Event Volunteers
Volunteers are the backbone of Software Freedom Day Bukidnon 2026, driving everything from pre-event preparations to post-event operations. We are proud to recognize the dedicated individuals who made this success possible:
Thank you for taking the time out of your weekend to show up, engage, and learn. Your energy, thoughtful questions, and collaborative spirit are what give life to the FOSS movement in Bukidnon. You are the future of our digital landscape, a thriving ecosystem where the veterans lift up the rookies, passing the torch to ensure the next generation keeps pushing boundaries.
The event has wrapped up, but our mission continues. The Free and Open Source Software movement in Bukidnon thrives because of community advocates and supporters like you. As we look ahead to the return of Software Freedom Day next September, we invite you to join us as a participant, volunteer, sponsor, or partner. Together, we can empower local tech ecosystems and drive collaborative innovation.
ای مهرِ دارندهی چراگاههای فراخ! به اسبانِ ما تندی و به تنهای ما نیرو ببخش، تا دشمنانمان را زیر نظر گیریم، آنان را فروکوبیم و هماوردان و دشمنان و بدخواهانمان را به یک زخم از پای درآوریم.
Time for another saturday recap of the week in longer form.
A interesting interrelated issue
A while back we moved our ansible control host to rhel10.
After this move, I noticed that the nightly job we run to run a
--check --diff over all our playbooks was taking a really long
time to finish. I added it to my todo list to look at sometime
but didn't think it was super high priority.
Last week we got some zabbix alerts about disk space on our central
logging host (log01). Usually when this happens, it's caused by some
openshift application crash looping or sending large tracebacks over
and over. However, that was not the case this time, as we had added
some checks to notify if that ever started happening so we could fix
things more quickly.
Looking at the (large) logs, it seemed like it was mostly builders
and mostly ssh-session messages.
Thinking these two issues could somehow be related, we started
digging into the check-diff run first. It seemed that ansible was
connecting to the target hosts, then just disconnecting again
and again in a loop. But why?
TLDR: If you specify multiple facts gathering modules (which we do
because we have one that gathers some python information), it tries
to do them in parallel, but there is a bug and it fails.
So, That was the base cause of both issues. check-diff was slow
because it would get stuck trying to gather facts (and get killed
after 24h by the script), and it was also causing tons of log messages
for each ssh connection which was filling up log01.
A simple:
ansible_facts_parallel: false
Fixed both things.
RHEL10 Database servers
Staging is all done, all servers there are postgresql 18 and rhel10
now. The last one was db-datanommer01.stg, which I did monday. Its
still a complex process, but it seems working and doesn't need a
intermediate rhel9 instance (as long as I am willing to upgrade the
existing one's timescaledb).
So, next thursday we have a outage and I am going to try and
migrate all the production database servers. I'll be glad when
they are all done.
I might try and do db-datnommer production a different day. Its
a lot more complex than the rest and might be good to get out
of the way seperately. Also, it's not super end user facing, so
it can probibly be down for a little while without too much ill
effect. Thats likely to be tuesday or wed.
Mass updates/reboots/outage next week
This is going to be a big one:
We are going to apply firmware updates on servers. This always
makes reboots take a while as they have to apply the firmware
upgrades.
We have some machines that aren't booting with secureboot enabled
and we want to fix those. Sadly that means a boot to setup, enable,
and another boot, which takes a while.
I am going to migrate all the prod database servers over to rhel10.
This is likely to take a while, but not too bad. There's no dump
restore needed, just 'fast' upgrades and shuffling things around
so the old rhel9 instances are retired and the new rhel10 ones take
their place.
Of course eariler in the week we will do staging and any hosts we
can take out of dns, etc... so thursday will mostly just be the bare
metal / vmhosts and their guests that we can't take down without an
outage.
Retour sur la migration UI de SeedboxSync de Bulma vers Bootstrap : pourquoi quitter un écosystème au ralenti, les limites de Bootstrap (Dart Sass, dark mode JS, balise progress) et les gains d'un framework riche en composants.
L'annonce de Portainer 3.0 confirme le virage stratégique de l'éditeur vers Kubernetes et les besoins des entreprises, laissant la version CE sur la branche 2.x. Un changement de cap qui confirme la pertinence de ma récente migration vers Arcane pour la gestion des conteneurs de mon NAS.
This year’s Akademy is over - at least for me. I’m already on a train on my way
back home, but there’s still plenty of people staying in Graz for more days of
hacking and fun. Even though I haven’t contributed to KDE much in the past few
years, I am really glad I decided to go.
First, I want to thank everyone from the organization and local team for
hosting us in Graz and orginzing a great Akademy. I know how much work it is,
so kudos to all of you <3.
I’m really happy that the community is in such a great shape. There’s a lot of
new people participating and contributing, which is a great sign! After all as
Cornelius showed in his talk - this year we have the most
people ever contributing to KDE - and the year is not even over yet!
This year we also voted the new KDE Goals. I am really happy that KDE for
Enterprise goal have been voted in. As someone pointed
out (with a little tongue-in-cheek): we’ve solved gamers, now it’s time to
solve enterprise. Kevin and the team in enioka Haute Couture are already doing
great work on KDE PIM thanks to the Sovereign Tech Fund. They
started with improving my akonadi-e2e-tests experiment and pushing it forward
to a point where it has helped them discover (and fix) many bugs in CalDAV in
IMAP - this is foundational work that everyone will benefit from. It’s
inspiring to see so much activity and many new contributors in KDE PIM again.
I attended another talk about making KDE “lovable” by Eva and
Jan. They discussed many things, but one that stood out to me, especially with
relation to the Enterprise goal, is that we should make sure that the
end-users, those who actually use our software in organizations, feel like they
gained something by migrating away from whatever they were running on before
and were used to. They should feel our software makes their jobs easier, makes
them more efficient and feel like it adapts to their needs - make it not just
usable, but /lovable/. I really liked that thought. How do we make KMail
loveble, though? That’s a tough one…
As for myself, I had a lot of schnitzels over the couple days, took a slide
down from Schlossberg, fixed some bugs and generally had a
great time. I managed to get KMail, KOrganizer and KAddressBook to compile and
run on macOS to the point that I can actually read and write emails. But
there’s a lot of fixes and polish needed still, more on that some other day.
All in all, it was a very fun, very productive and very inspiring Akademy for
me, and I can’t wait to see everyone again.
A somewhat busy week for me, so lets get into it..
RHEL10 Database migrations
So, I had finished off all the staging databases except for one the week before,
so I spent a fair bit of time this last week looking at the last one.
It's a pretty fun case, our db-datanommer.
This is the database that stores all the messages that go accross our message
bus and allows you to search them via datagrepper. Because of the nature of
the data in it, it uses the timescaledb extention on top of postgres.
It's currently (in both staging and production) a rhel9 vm with postgresql 13
and timescaledb 2.10.1.
Before getting into the fun set of constraints, I'll mention that I am a
paranoid sysadmin. This means I always think about 'what would happen if
this migration fails there, or there' So I strongly prefer to leave something
in a state where I can backout to it if something goes wrong. So, in this
case I strongly prefered to just leave the existing vm alone an dmigrate to
a new one, and if something blows up, can just move back to the old one.
So, the constraints were pretty fun here:
timescaledb has a handy chart about which versions support which postgres
versions. 2.10.1 doesn't support 16 or 18. No versions support both 13
and 18. 1 version does support both 13 and 16 however.
rhel9 actually has postgresql-16 available, but as a module. Because it's
a module it makes it hard to build normal rpms against it.
dump and restore of the db would take way way way too long as a pg_dumpall
(sql) dump. The pg_dump formats would be faster, but not all that much because
timescaledb doesn't work with -j (N jobs) on restore.
rhel10 has postgresql16 (default) and 18 available as seperate packages.
When you upgrade from 16 to 18, you need to either enable data page
checksums (running a tool over the db's) or make 18 start without them.
They sound like a really good idea though, so I wanted to enable them
So, in order to do this under all my constraints it would require 3 vm's:
The current one (untouched), another rhel9 one to sync the data to, upgrade
timescaledb on, then sync that to a rhel10 one to upgrade to 16 and then
another timescaledb upgrade and upgrade from 16 to 18.
In the end though, it seems like timescaledb upgrades are pretty smooth and
easy, so I decided (at least in staging) to just upgrade timescaledb to 2.13.1
(which supports both 13 and 16). That allows no intermediate rhel9 vm.
So, thats the plan, but there's more gotchas I hit along the way:
When upgrading from 13 to 16, you have to also have timescaledb from the
13 install installed in the right place for the upgrader to use it.
You also need to modify the template postgresql.conf file the upgrader
users to enable timescaledb, or else when it upgrades it blows up
at the end because there's a missing extension.
Both those last 2 things apply for 16 to 18 too.
The upgrader also helpfully tells you to look at some log when things
fail, but it's the log from the data dir it JUST DELETED BECAUSE IT FAILED!
I ended up reading those logs by running the upgrader under strace. :(
After all that, I think I have a process now. I was going to do the staging
one friday, but I made a stupid mistake (putting the 13 timescaledb.so in the
wrong dir) so I ran out of time. Will move it monday.
Mass firmware update/mass reboot/database migrations
So, with the last database server sorted in staging, time to get production
done. We are tenatively planning an outage for 2026-10-01, the thursday
before final freeze. Hopefully we can get all the databases done then.
Of course this will jinx things, but things have been reasonably quiet
on the scraper front of late. There was some activity where they
were hitting our wiki really hard, but luckily it was reasonably easy
to block them in that case. It did cause problems for other services
however as it caused our proxy network to hit max connections.
Otherwise it's been quite nice not to have to battle them day to day
so much.
I am booting VMs via qemu (no libvirt) and sometimes they don't tell me what IP address they got when booted. To figure it out, considering I know the IP address, I can query the network via the Address Resolution Protocol (ARP)
I know they get address in sequence, so:
ayoung@sut11sys-r112:~/devel/ampvirt$ arp -n | grep -i "52:54:00:70:0c:"
10.76.112.154 ether 52:54:00:70:0c:02 C virbr0
10.76.112.153 ether 52:54:00:70:0c:04 C virbr0
10.76.112.155 ether 52:54:00:70:0c:03 C virbr0
It’s been about 4 months since my last GNOME Foundation update. Time flies. I’m sorry that it’s been so long. I will try to do more regular posts again in the future, but perhaps not at the same tempo as before. While I would love to post every other week, it’s hard to sustain.
With that said, let’s jump in. Given the time since my last post, I’m going to focus on the bigger and more recent news items that have happened at the GNOME Foundation.
New board, new officers
The Foundation’s board elections happen every year, and this year’s election completed in July. The election resulted in a number of changes to the board:
Sri Ramkrishna, Jonathan Blandford and Adrian Vovk joined the board as new/returning directors
Deepa Venkatraman, our treasurer, secured a new two year term
Robert McQueen, Federico Mena Quintero and myself all ceased to be directors (Rob failed to be re-elected, Federico didn’t run, I withdrew part-way through the process)
The election was a difficult one for me personally, and left me reconsidering my involvement in the Foundation. This was not because I lacked motivation or commitment, but because the situation around the election had become untenable for me personally. However, I’ve spent a good deal of time since I withdrew my candidacy thinking about my role at the Foundation, and I’ve concluded that I care about this organisation and the progress we’ve made, and I want to see that work through. Conversations I’ve recently had with members of the community have also given me confidence that we can move forward together. In short: I’m happy to be sticking around.
The new board held its annual meeting in August, which is when officers and committees are appointed for the next 12 months. The Board decided to put me into position as Interim Executive Director, with Sri Ramkrishna taking my place as President. This is a good move from my perspective: it recognises that I’ve been doing a lot of the day to day management work (which I will continue to do), and gives the Board more ability to hold me accountable. Sri stepping into the role of President means that he will be my backup.
Other officer changes include Jonathan coming in as Second Vice-President, Cassidy moving from Vice-Secretary to Secretary, and Adrian stepping up as Vice-Secretary. Our other officers remain in post, with Maria as chair, Deepa as Treasurer, and Arun as Vice-President.
Huge thanks to everyone who volunteered for these positions!
In terms of committees, the Executive Committee had a minor reshuffle, with Jonathan, Adrian, and Sri joining, and Julian and Rob departing. The new members of the exec are already taking on work, which is great, and I’m hopeful for the newly reconstructed committee. The Finance Committee had some slight membership changes, with Rob leaving and Sri joining.
Finance and Operations Director
Last April we opened the search for a new paid team member, to join us as our Finance and Operations Director. There are a number of goals for this new position: to enhance the finance and accounting expertise that we have internally, to lead the development of our internal systems and budgets, to ensure the sustainability of finance and compliance tasks, to manage our fiscally sponsored projects, and more generally take ownership of the business side of the organisation.
We had a huge number of applicants apply for the position, and had some extremely high quality candidates to choose from. After going through several rounds of interviews we selected Dawn Matlak for the role, who we are extremely excited about joining us. Those of you who have read my previous posts might remember Dawn’s name: she initially started working with us as a consultant last year, in order to help us prepare for our first formal audit, which happened in March this year. As part of this work she helped us to transform many of our internal systems and processes. We’re thrilled that she is joining the Foundation on an ongoing basis, and are confident that our internal operations will continue to improve under her stewardship.
Dawn is already doing a small number of hours for us each week, which she will continue to do until she properly starts in the role in November.
Many thanks to Arun and Deepa who helped enormously with the hiring process.
FY27 Budget
The Foundation’s financial year runs from 1 October to 30 September, and each financial year requires a new budget, both for planning and as the basis of reporting and spending authorisation. We have all therefore been working hard on the new budget that will come into effect on 1 October. The new budget has been in the works for a while, and has been a major focus for the board over the past few months. Thankfully we got the initial budget approval done last week at the board’s regular September meeting. We’ll follow-up with a more detailed post about the budget as soon as we’re able, so the community can have some insight into how we’re managing our finances.
Events
With GUADEC 2026 wrapped up, Kristi has turned her attention to the next event in our schedule: GNOME.Asia 2026. This is being held in Terengganu, Malaysia, from 31 October to 2 November. There’s a great venue lined up, and Kristi is busy working on the details with a fantastic local team.
Aside from GNOME.Asia, the other recent focus has been GUADEC 2027. We have a couple of options for locations right now, and are in the process of confirming details before we commit to one of them for next year. We’ll share updates as soon as we have more details confirmed.
Fundraising
The end of the calendar year is an important time for non-profit fundraising, and we are currently busy planning our campaign for the end of 2026. I’ll be posting more about this soon, in particular in relation to the budget, but for now I will say that this campaign is going to be critical for our ability to grow and support the GNOME project.
Other
As ever, many other things have been happening at the Foundation, and there’s too much to go into detail about here. Work on GNOME’s infrastructure and Flathub continues, our back office operation continues with finances and other routine paperwork, and the board continues to discuss our long-term plans.
That’s it for now. Many thanks for reading, and feel free to leave questions in the comments.
On Saturday, August 22, 2026, the Fedora Project joined forces with openSUSE at Data Con LA 2026, hosted on the campus of California State University, Long Beach (CSULB).
Now in its 14th year, Data Con LA is Southern California’s largest gathering of data professionals, students, and practitioners covering data science, AI/ML, and data engineering. While Data Con LA is not a traditional Linux-centric conference, our presence offered a unique, hands-on opportunity to engage a fresh audience of prospective contributors, test our event planning workflows, and showcase Fedora Workstation in action.
As part of our ongoing work to standardize the Fedora Ambassador event pipeline, this report reflects on our operational outcomes, what worked well, and key lessons learned for future event organizers.
1. A Standout Win: “A House with Many Rooms” (Co-Hosting with openSUSE)
Our standout operational victory at Data Con LA was co-locating and sharing table space side-by-side with openSUSE advocates (coordinated with Patrick Finie / mir and Drew Adams).
Rather than maintaining isolated tables, we embraced the philosophy of “A House with Many Rooms.” This cross-community collaboration was an immediate force multiplier:
Shared Energy & Presence: Combining our presence effectively doubled our footprint and visual appeal, turning our shared booth area into a high-energy focal point in the expo area.
Seamless Staffing & Rotations: Having four volunteers across both distributions allowed for seamless shift rotations during peak traffic and lunch breaks, completely preventing booth fatigue.
Cross-Promotion: When attendees visited our table, we engaged them collaboratively by directing people to open source solutions across distros based on their specific technical needs and interests.
For future community organizers planning small-to-medium booths, establishing a shared booth with allied open source projects is an operational model we strongly recommend.
2. Demographics & Lead Engagement
Over the course of the day, our booth engaged approximately 100 visitors (110% of our initial goal), with peak traffic occurring during the post-keynote morning rush (9:30 AM – 11:00 AM) and lunch transitions (12:30 PM – 2:00 PM).
The attendee demographic offered valuable insights into the broader tech ecosystem:
Student & Alumni Presence: The majority of visitors were CSU Long Beach undergraduate and graduate students, alumni, and local data practitioners.
First Encounters with Linux: Roughly 10% of attendees were active Linux users; for the remaining 90%, Data Con LA was their first direct introduction to Linux and Fedora.
Lead Qualification Breakdown:
Hot Leads (30): Inquired specifically about Fedora, visited the website, and expressed interest in installing Fedora Workstation or exploring the Join SIG.
Warm Leads (20): Asked for links to documentation, Fedora Discussion forums, Matrix channels, or local user groups (such as SGV LUG in Pasadena and SFV LUG in Northridge).
General Engagements (10+): Discussed general data industry trends, tech careers, or university studies.
3. The Technical Showcase: Local AI on Fedora Asahi Remix
To connect directly with the conference’s AI/ML focus, we showcased a fully offline, containerized local AI demonstration running on an Apple Silicon laptop.
The Setup
Hardware: 2020 Apple M1 MacBook Air (8 GB RAM) dual-booting macOS.
Software Stack: Fedora-native Podman containers running Ollama alongside Open WebUI, exposing a private, ChatGPT-style web interface at localhost.
Model: llama3.2:1b (sized appropriately for the laptop’s 8 GB memory ceiling).
Why It Resonated
This demonstration served as a major crowd-pleaser across two distinct attendee groups:
Data Professionals & Privacy: Attendees expressed fatigue with commercial operating systems that enforce invasive telemetry and proprietary cloud AI features. Highlighting how Fedora enables private, offline LLM inference with zero data leakage resonated powerfully.
Students on a Budget: CSULB students loved seeing how Linux can revive older, restricted hardware to deliver a capable, subscription-free AI workspace without requiring expensive cloud API tokens.
4. Advice & Lessons for Future Event Owners
If you are planning to organize a small event (under $150) or booth presence in the next six months, here are four practical takeaways from our experience:
Design 100% Offline Demos: Campus and conference Wi-Fi networks are notoriously unreliable, firewalled, or slow. Designing our demo to run entirely inside local Podman containers without requiring an internet connection kept our booth fully functional all day without friction.
Account for Outdoor Environmental Factors: Our booth was located in an outdoor expo space. During the afternoon peak heat, direct sunlight caused our demo laptop to heat up, requiring us to tuck it under banners in the shade. Recommendation: Always confirm booth coverage in advance, and pack brimmed hats, pop-up shade, or cooling accessories if outdoor placement is unavoidable.
The Power of the Daily User Perspective: You do not need to be a kernel developer or upstream maintainer to staff a Fedora booth. Sharing how you use Fedora day-to-day for work, study, or home projects alleviates “imposter syndrome” and provides relatable, authentic guidance that newcomers appreciate.
Keep Swag Requests Lean on Short Timelines: Because our event planning window was short, we kept our Forgejo Mindshare swag request focused strictly on high-impact essentials: stickers, case badges, and pens. Podman and Fedora logo stickers drew in decision-makers and students alike.
5. Next Steps & Wrap-Up
We would like to thank Patrick Finie, Drew Adams, and the openSUSE community for partnering with us, as well as the CSULB organizers for putting together a fantastic event.
Following Data Con LA, our team of Ambassadors Perry Rivera and Rob McBryde are incorporating these lessons directly into the new Small Events Standard Operating Procedure (SOP) and preparing for upcoming community participation at SCaLE. Our intention is to share and publish this information in the Fedora Docs website so that other event owners in the Fedora community may benefit from common wisdom from others who have done this work before.
Want to get involved? Connect with us on Fedora Discussion or drop by the #ambassadors:fedoraproject.org Matrix channel!
نسخه بتای Fedora Linux 45 از امروز، ۱۵ سپتامبر ۲۰۲۶، در دسترس علاقهمندان و آزمایشکنندگان قرار گرفته است. کاربران میتوانند نسخه بتای فدورا ۴۵ را دریافت کرده و پیش از انتشار نسخه نهایی، قابلیتها و تغییرات جدید این نگارش را آزمایش کنند. فدورا همچنین امکان ارتقای سیستمهای موجود به نسخه بتا را از طریق ابزار DNF […]
در بخش ۱ به صورت کلی Podman معرفی شد و نحوه کارکرد آن توضیح داده شد. در این مطلب قصد داریم تا آن را نصب و استفاده کنیم. نصب Podman در فدورا لینوکس در فدورا لینوکس معمولا پادمن به صورت پیش فرض نصب می باشد، ولی به هر حال روش نصب به صورت زیر می […]
It’s been 7 years since I last posted such a banner, and just today I remembered how I was always
excited about this kind of posts, so here we go. I’ve also been to Akademy in Würzburg 2 years ago,
but didn’t post the banner for some reason (silly me!).
I haven’t really contributed to KDE for quite a while, but Akademy is always worth attending, even
just to meet old friends again and make some new ones. Plus this year is KDE’s 30th birthday. KDE
has been such a huge part of my life, so I am not going to miss such an anniversary.
Andreas Gabriel Berbescu has reported several root privilege escalation vulnerabilities in various NetworkManager VPN plugins. If the VPN plugin is installed, then an unprivileged user can escalate to root by loading a malicious VPN configuration file:
September 25, 2026 Update: There is also CVE-2026-75131 and CVE-2026-75883 for NetworkManager-l2tp. I didn’t know about this because it is not a GNOME project.
While most obviously bad for multi-user systems, root privilege escalation is also a serious defense in depth problem for single user systems. You are vulnerable if you have the VPN plugin installed; it does not matter whether you actually use it or not.
These are not vulnerabilities in NetworkManager itself. The VPN plugins are each separate projects, with their own separate maintainers, hosted by GNOME rather than by freedesktop.org. The status of each project is a little different:
$ spctl -a -v bin/SimpleShell.app bin/SimpleShell.app: accepted source=Notarized Developer ID
I was searching for a good quality but simple free open terminal for MacOS and I couldn’t really find what I was looking for interface wise (I used to use iTerm for a long time but it started getting more and more bloated and laggy on me – using up a lot of system power on battery and I don’t want all that AI stuff baked in).
I started a project earlier this year but got stuck on it because I was trying to implement a basic ANSI parser which was a mistake on my part. I didn’t realize how incredibly complicated that finite state machine would be, esp with bash and ansi apps sending complicated instructions into the machine! I then asked Google AI for help and it pointed me to a GitHub page that hosted a libvterm (from vim) that was compatible with Objective-C.
I’ve been working on this app non-stop for the last 9 days now and I only have the basics covered, I didn’t realize how much code it took just to make a basic text processing input/output app but I think this is one of my more complicated code bases (possibly TurnTable is the other app of mine that might be more complicated but that one is in Swift).
I still have a lot more work on my todo list for and I will continue development on it now that I got ANSI parsing to work, the rest is just mainly ViewController and functionality features. I targeted it for the bash shell so I don’t know if it works with other shells but this is just my first release post about it.
Layout List
Date (Month / Day)
Terminal (Rows / Cols)
Network (LAN / WAN)
System (CPU / RAM / NET)
WiFi (Freq / Rate)
Highest Process (PID / MEM)
Shell PS1 Prompt Info (User / Directory)
Dynamic Prompt Prefix Information Insertion (Any scriptable line items)
Feature List
Simple Clean Minimal Functional Design
Window / View / Layout — Colors / Opacity / Blur
Selector / Highlighter Separator Character List (Automation)
Auto Copy On Selection (Automation)
Single-Line Paste Manual Enter (Safety)
Multi-Line Paste Prevention Protection (Safety)
Huge-Line Paste Limitation Protection (Safety)
Multi-Window / Multi-Tab
Left Aligned Tab Titles With Monospace Font (Readability)
Scriptable Standard Window And Tab Title Text
Scriptable Dynamic Shell Prompt Prefix (Found No Where Else!)
Always Visible Command Line Prompt (Found No Where Else!)
Live System Information Stats Bar
Separated Open / Close Tab Buttons To Reduce Accidental Closures
Multi-Tab Window Detection To Reduce Accidental Closures
Dual Output Modes (line/ansi) With Separated Input Prompt (comd)
Smooth Scroll Locking
Clear Console Command
Easy Use Shortcut Keys (cmd/opt + left/right)
Regular Expression Search
Basic Output Text Colors
Basic Process Job Detection
Transparent Rounded Cursor Block!
Dock Icon!!
Todo List
Add settings for font text type / size
Add settings for ansi color codes
Limitation List
Tabs Can’t Be Transferred To Other Windows
Only Reopens One Window / Tab On Launch
No Previous History Or Information Is Restored
Warning List
User Beware: This is still a brand new framework and there may be bugs (or at the very least incompatibilities)!
Another saturday, time for another recap of interesting things in longer form.
RHEL10 database migrations
I managed to migrate all but one database server in staging.
No particular problems with those and they are all on postgresql 18 now with
data page checksums enabled (well, except the single mariadb instance,
and it's on 10.11.18). Hopefully I can get the production ones
done in the next outage we have (probibly the week before final freeze).
The last staging database server is more interesting: db-datanommer01.stg
This is using timescaledb on top of postgres and is currently the rhel9
default version: 13.
After looking around, I think this one is doable, but needs another step:
sync a data backup off the existing server
upgrade it to postgresql 16
enable data page checksums
install a new rhel10 vm
sync the data to it
upgrade to 18
install the correct timescaledb extension
take down the old instance and swap in the new
I think this will all work, just an extra 13->16 jump. I will try it out
in staging next week. I'm also a bit worried about how long it will take
to generate all those checksums. The datanommer db's are really large.
However, if we can do it I would love to as it's a very nice feature.
Doing staging should at least give us an idea.
Fedora 45 Beta is go for release next tuesday ( 2026-09-15 )
Looks like we are go for fedora 45 beta next week.
I hope everyone will test it out and help us iron out
any problems before the final release.
It’s been another fantastic year for Google Summer of Code with GNOME! This year, six contributors worked on a range of interesting projects across our ecosystem.
Our contributors have been blogging about their progress on Planet GNOME throughout the summer. In case you missed their updates, here is a breakdown of what they have worked on:
This would not have been possible without the support of our community mentors. A huge thank you to Jonathan Blandford, Federico Mena Quintero, Alex Băluț, Yatin, Adrian Vovk, Jonas Ådahl, Robert Mader, Carlos Garnacho, and Philip Chimento. Mentoring takes a lot of time and energy, and it plays a vital role in onboarding new contributors to our community.
If you are a GNOME developer and interested in mentoring a project next year, you can already start working on your project ideas and submit them at gitlab.gnome.org/Teams/internship/project-ideas.
If you are a newcomer interested in starting your journey toward becoming a GNOME contributor, check out gsoc.gnome.org and stay tuned to Planet GNOME and our social media channels for updates on the 2027 program!
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.
RPMs of PHP version 8.5.11RC1 are available
as base packages in the remi-modular-test for Fedora 43-45 and Enterprise Linux≥ 8
as SCL in remi-test repository
RPMs of PHP version 8.4.26RC1 are available
as base packages in the remi-modular-test for Fedora 43-45 and Enterprise Linux≥ 8
as SCL in remi-test repository
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.
After much back and forth and hoops jumping, I can finally reveal nouveau/nvk running on a NVIDIA Spark box.
This is running on a version of nouveau[1] that has
a) ported to the 610 NVIDIA firmware
b) a bunch of display rework from Moham
c) a bunch of 0 VRAM and L2 cache handling fixes
d) spark boot support
e) spark display support
and NVK[2] with patches to handle gb10 depth/stencil differences and 0 VRAM support.
I'm not sure how best to upstream it all, it's 100 patches and a new firmware which might mean it's a wait for nova type situation, but I just wanted to see it work.
ebtables -t nat -A PREROUTING -i wifi+ -p IPv4 --ip-proto udp --ip-sport 67 -j DROP
~
[kmod-nft-bridge]
table bridge ethernet {
chain PREROUTING {
type filter hook prerouting priority filter; policy accept;
iifname "wifi*" arp operation reply arp saddr ether != 00:11:22:33:44:00 arp saddr ip 192.168.1.1 counter drop
iifname "wifi*" ip protocol udp udp sport 67 counter drop
}
}
~
OpenWRT Config
wireless.default_radio0.isolate='1'
wireless.default_radio0.bridge_isolate='1'
~
Untested Commands
bridge link set dev wlan0 hairpin off isolated on
ebtables -A FORWARD -i wlan0 -o wlan0 -j DROP
~
Note: Most of these commands won’t work on UAP-U7-PRO APs I believe due to hardware based frame/packet routing/forwarding – I have since enabled arp-proxy and dhcp-snooping in the UI network controller application, however, I don’t see them working either, possibly because I am running a third-party gateway device. I have finally enabled client-isolation, which as tested, solves the ARP and DHCP attacks completely and forces client-to-client communication through the router instead for even further filtering!
I have first since used a couple web based AI systems for different specific tech things and they are pretty useful if you do the extra work to verify and modify what they are telling you. I’ve found that Google Gemini AI is really good a general tech questions and configuration items (with looking it over and understanding it and modifying it of course for your specific needs) and Claude Sonnet AI is really amazing at verifying that your code is correct and other more in-depth programming related tasks (for example, memory allocation and pointer handling and file descriptor tracking). I was also trying to test and see if the AI system would learn from me or others over time and add that previous historical context for each conversation into future interactions.
I’ve been using these systems lightly whenever I get stuck and they are able to find the exact code snippets I was looking for to complete the rest of my projects – prompt engineering!
Tips:
You need to try and give as much extra debugging info that you can for it to properly figure things out or update its answer
It’s better to ask it small specific questions and break the problem apart into pieces and then tailor a customized solution
There are interesting differences between asking it high-level design questions versus low-level coding questions
It’s also interesting to ask it open-minded / open-ended questions versus asking for specific solution implementations
It may get lost easily depending on code length, complexity, and the given language it is programmed in
Sometimes it will loop through repeated answers if it gets stuck on one specific solution
Sometimes the quality of a given answer decreases the longer that you interact with it
Sometimes you will get varying, differing, or conflicting answers if you re-ask it the same question
Sometimes it gets stuck on one specific solution that won’t work in the end but if you try to ask it how to approach the problem from a different angle it can provide steps for you to get extra info for it to either re-fine or re-suggest its solution
Note: It’s a shame that AI resources are being used on social or political issues rather than solving technology and scientific issues to help progress humanity. I’m still amazed that I was able to feed a 1000 lines of C code to Claude as a test and it was able to determine the components purposes and the network proxy applications of it all…
Google AI seems a little more friendly and personable whereas Claude is more on task and professional ha
This week seemed to have a lot of small irq's all around.
That said, I did make some progress on a few things:
RHEL10 migrations: databases
Next up on the migration train: databases. It turns out we already
had one database server in staging moved to rhel10, but it was using
the default postgresql 16 and since I am going to the trouble to migrate
things to a new os, might as well move them to newer postgresql too.
postgresql 18 makes data page checksums default. You can disable them
at startup if you really want to, but they seem like a really good idea
to enable. So, I took db-koji01.stg down and added checksums and it took
around 45minutes. Not super great, but not nearly as bad as it could be.
Then, the upgrade to 18 was super fast and painless.
I did some work in our ansible repo to set up rhel10 hosts with postgresql18
to start with and created a db-fas02.stg to migrate that to.
The rest of these servers will follow basically this pattern:
Setup a rhel10/postgresql18 02 vm for each server
Sync data from rhel9 one.
Stop rhel9 one (OUTAGE)
Sync data again from rhel9 one.
Enable data page checksums
Migrate from 16 to 18
Profit
I hope to get the staging ones all done next week and find any issues,
then we can look at scheduling an outage after Beta freeze to do all the
production ones.
Laptop Battery replacement
My lenovo slim7x battery was getting pretty pathetic. It was 2 years old
and it's max full capacity was something like 35% of design full and
sometimes it was now refusing to charge without a reboot.
So, I ordered a new battery and installed it this last week.
This laptop is anoying to work on because, while there are screws on the
bottom panel, it's also held on by clips. So you have to pry it off and
it sounds like you are breaking it while doing so. Anoying.
Also on this laptop they routed all the cables around the battery.
The battery has cable guides all around it. So, to replace the battery
you have to move all those cables carefully and slide the old battery out
and new one in, along with unplugging the bluetooth and wifi antennas,
and disconnecting/connecting the battery connector.
I did manage to do it, but it took more time that I thought it would.
While I had the machine open I swapped the windows drive I had back
in and updated the firmware (which there's no way to do from linux).
It was quite a pain. windows took quite a while to notice that it
was not 2024 and that it should check what _current_ updates were
available. Did manage it in the end. I don't know what effect the newer
firmware has, everything still works the same as far as I can tell.
Fedora 45 beta rc's
We have started making rc's for beta. That sure reads weird, but
if you are able, please do test and file bugs.
Authentication issues
There's one weird auth issue I am aware of. Thats where services
with keytabs are sometimes getting permission denied. It seems to be
somehow some differing config on two of our ipa servers.
Thats being tracked in https://forge.fedoraproject.org/infra/tickets/issues/13539
I am not aware of any other issues remaining.
So, if you hit something, please do file a ticket and include enough
information for us to try and fix it. ie, time/date, exactly what you were
trying to login to, exactly what error message you got, etc.
One of the hot topics in the last months has been the use of “AI” — which
usually means using LLMs (Large Language Models).
After a big push at work to adopt “AI”, it took me some time to find a good use
of it in my daily workflow.
Rewriting software
One of most popular ways of using “AI” is rewriting software. I know people
having old games ported from one retro platform to another this way.
However, the low barrier to entry gave many people a way to jump in which did
not end well…
As a result, countless projects have stopped accepting merge requests because so
many of them were nothing more than “AI slop” (aka “worthless junk not even
worth looking at”).
I would not send anything like that to anyone for review. Far too messy.
Going through it was painful but I got what I asked for. And this was a result
of several prompts and manual changes.
Fixing packages
As you know, my work is mostly around building packages. I have worked on Arm,
AArch64, ppc64le, s390x and now RISC-V. I fixed countless packages by hand,
going through their source and finding out why they failed and how to get them
building on target platforms.
After my last vacation I decided to check how an LLM would help with it.
I fetched the package, unpacked the sources (fedpkg prep), fetched the
build.log file from the latest failed build, and ran Claude with one, simple prompt:
Look at build.log and source and find out why it does not build on risc-v.
The amount of time I had to wait and output to read varied from package to
package. Sometimes build logs from other Fedora architectures were needed,
sometimes a few build attempts. At the end I had a patch which made the package
buildable on the RISC-V architecture.
Types of fixes
Some fixes were simple, like
fastnetmon where
a change in the link order was the only thing needed.
Some were funny, like GNU Data Language
where fixing RISC-V fixed it for AArch64 as well. This made the build fail, as
some tests, which were expected to fail, passed.
Others were related to differences between RISC-V (RV64GC) floating-point unit
compared to other architectures. Such “simple” things like “are we dividing
by zero” can be a problem.
Things I do not send
There were also packages for which I got some patches and never sent them
neither upstream nor to the package maintainer.
Those were ones I did not understand. For instance, a patch changed how the “R”
language handles “NA and NaN” numbers. It was yet another issue related
to how RISC-V FPU works. Also it was so cryptic that I looked at code and had no
idea what I was looking at.
The final question
I understand FOSS developers who refuse to accept any “AI generated” changes.
There is too much “AI slop” being submitted. At the same time I wonder where
their limit is.
Would they merge patch below or not? And would presence of the “Assisted-by:
LLM” line make them refuse this patch or not? Will they accept it without such line?
Subject: [PATCH] Fix abseil link order for ld.bfd
Move absl:: libraries after gRPC in fastnetmon_api_client link list.
ld.bfd (used on riscv64) is a single-pass linker and needs dependees
before dependencies.
Assisted-by: LLM
---
src/CMakeLists.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 10caf4c6..5bde9fcc 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -800,10 +800,6 @@ if (ENABLE_GOBGP_SUPPORT)
add_executable(fastnetmon_api_client fastnetmon_api_client.cpp)
- if (LINK_WITH_ABSL)
- target_link_libraries(fastnetmon_api_client absl::base absl::synchronization)
- endif()
-
# We use another way to specify dependencies for Windows as our standard approach clearly does not work
# https://www.f-ax.de/dev/2020/11/08/grpc-plugin-cmake-support.html
if (${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
@@ -819,6 +815,10 @@ if (ENABLE_GOBGP_SUPPORT)
target_link_libraries(fastnetmon_api_client protobuf::libprotobuf)
+ if (LINK_WITH_ABSL)
+ target_link_libraries(fastnetmon_api_client absl::base absl::synchronization)
+ endif()
+
if (KAFKA_SUPPORT)
target_link_libraries(fastnetmon ${LIBKAFKA_CPP_LIBRARY_PATH})
endif()
I would accept it. Because for me, despite the origin of that patch, it is a
very simple change to review.
Once again, GNOME is considering participating in the Outreachy internship program. Outreachy provides internships to people subject to systemic bias and impacted by under-representation in the tech industry where they live.
Outreachy internships are funded by the participating communities. While the GNOME Foundation has not yet finalized the budget for this cohort, having a strong list of proposed projects and available mentors helps the Board decide how many slots to fund.
Project ideas will be selected based on available funding and their relevance to the overall goals of the GNOME project. Project selection will be handled by Matthias Clasen, Allan Day, and Sri Ramkrishna.
If you are a GNOME developer/maintainer available for mentoring between December 2026 and March 2027, please submit a project proposal at gitlab.gnome.org/Teams/internship/project-ideas as soon as possible (by September 11).
It’s hard to evaluate the security of open source projects when security bug reports remain private forever. Users deserve to see security bug reports, so please remember to unset issue report confidentiality when you’re done handling an issue. There are very few good reasons to keep an issue report confidential forever. If you’re not planning to disclose the issue report within the next few months, it should probably already already be public.
For GNOME, I disclose issues whenever a merge request has been created or a fix lands in the git repo, or 30 days after the issue was reported, whichever comes first. Your project might prefer to wait until the fix is released before disclosing, especially if you fear that a vulnerability might actually be exploited during the window between the fix and release. Whatever you choose, please don’t forget about it and leave the issue report confidential forever. That’s not fair to your project’s users. Even if not many people will take the time to look, users should at least have a chance to see reported issues.
For a while now, the fingerprint management UI in GNOME Settings (gnome-control-center) has felt outdated. While it worked, the layout and enrollment flow hadn’t kept up with the rest of GNOME’s modern interface updates.
I am happy that during the GNOME 51 development cycle we managed to address that. Allan Day, Marco Trevisan, and myself worked on modernizing the interface. There’s still more work to do in the UI and in fprintd, but what we will ship in 51 is already a great step forward.
Historically, the fingerprint dialog in User Settings was stuck on a GTK3-style design. Even after being ported to GTK4, conceptually it remained unchanged. Beyond looking out of place alongside Libadwaita-based settings panels, it suffered from responsiveness and accessibility issues that made it difficult for some users to enroll their prints.
Screenshot of the Fingerprint Authentication dialog
The new fingerprint management dialog uses a standard boxed list displaying your enrolled fingers. From here, each enrolled finger can be removed individually.
Clicking the “Add Fingerprint” button starts the finger enrollment process. First, you choose one of the unused finger options to enroll. From there, an assistant guides you through the scanning process. As you place your finger on the reader, the UI detects the touch and provides feedback on whether it was read correctly. You continue touching the reader until enough samples have been collected (the exact number depends on your reader’s driver). Once the progress bar fills, your finger is ready for authentication.
Screenshot of a fingerprint enrollment
This is only one of the improvements that GNOME 51 is bringing. As with everything in GNOME, we will continue gathering user feedback and making iterations over time. There are already more fingerprint features in the pipeline, such as renaming enrolled fingers and verifying individual prints. Stay tuned!
I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.
This is because I was planning to leave my job at Red Hat on December 31 due to some internal Red Hat policy changes. But this timeline has now unexpectedly moved forward two months, to October 30. Accordingly, I will now discontinue tracking newly-reported security issues on October 1, 2026. During October, I will focus only on tracking issues reported prior to October 1. By November 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.
If your agentic workload involves the agent being able to run arbitrary code
(like bash or equivalent), then you should not use a “LLM as part of your
app” framework like LangChain,
BeeAI,
OGX etc. Instead, run OpenCode, goose, or another general coding agent
inside a sandbox such as OpenShell.
Sandboxing limits what the agent can access directly. For privileged effects,
it is best augmented with a pattern like
safe outputs: the
agent emits a structured, unprivileged request that separately trusted code
validates and applies.
A compact decision tree
Can it run bash or arbitrary code?
├─ Yes → Run a generic agent in a sandbox
└─ No → Are you *really* sure *all* of your tool calls (MCP or builtin) don't accidentally expose "execute arbitrary code"?
├─ Yes → OK, maybe LangChain or equivalent makes sense
└─ No → Goto start
I also think the builtin sandboxing in most agent tools (like Claude Code
and Gemini CLI) is a bad idea, and it’s better to just ensure the entire
thing is sandboxed.
Related to all of this, a key thing anyone making an “agent” needs to ask is “how is this different
from just writing an agent skill”. From my
previous post
you’ll know that I think GitHub Agentic Workflows is a good reference baseline
for applying agentic AI (background/task oriented) safely and effectively. And there an “agent” is
almost exactly just an agent skill, but with a bit of YAML defining its integration
with the outer system.
Why should it be harder than that? I just don’t see it making sense for custom agents written in frameworks like
LangChain to proliferate in most use cases. Sure you can use LLMs to generate
it, but it’s even more secure and understandable to not have that code at all.
Even for the use case of an interactive chat bot, do you really need a custom
app versus just MCP tools for an already generic frontend? I doubt it.
I don’t think it makes sense for most organizations to have proliferation of custom bespoke
agents like these LangChain-style frameworks encourage. Skills and sandboxed
generic agents are just easier to understand and work with.
This is an independent, censorship-resistant site run by volunteers. This site and the blogs of individual volunteers are not officially affiliated with or endorsed by the Fedora Project.
![VMS Enterprises Ltd vs The Brexit Party Ltd ([2021] SC GLA 49), 11694875, 16260766, CR-2022-003973](https://danielpocock.com/assets/reform-uk/2021scgla49-vms-enterprises-ltd-against-the-brexit-party-ltd-cover.jpg)
![Reform UK, Nigel Farage, creditors, [2021] SC GLA 49](https://danielpocock.com/assets/reform-uk/vms-brexit-research-article.jpg)
![Reform UK, Nigel Farage, Brexit Party, 11694875, 16260766, CR-2022-003973, [2021] SC GLA 49](https://danielpocock.com/assets/reform-uk/gazette-side-by-side.png)
