fidzu : Fedora

Lately, it seems the industry is aggressively pushing immutable, image-based operating systems for the desktop. Shipping a cryptographically sealed, read-only root filesystem sounds super fancy and elegant on paper, but in reality, it's a solution looking for a problem, unless you're running a smart fridge or a corporate kiosk.

Let me be perfectly clear: immutable systems are the correct choice for single-purpose appliances, point-of-sale terminals, and sealed server nodes. If your hardware only needs to run a fixed set of remote directives without any user intervention, then yes, a mutable root filesystem is just begging for trouble.

But trying to force this architecture onto a general-purpose desktop? That is a spectacular regression. It wraps the user in a straitjacket, offloads system complexity onto you, and strips away ownership, performance, and actual security in the process.

Here is the engineering reality of why the immutable desktop fails the general user.

18 Jun 2026 7:00am GMT

La neta, a veces el internet te da sorpresas chidas. Hace unos días, un compa en la red me ofreció donar dos servidores virtuales para mi proyecto de MxOS. ¡Un parote, la verdad! Pero como en todo, siempre hay un "pero": las únicas opciones de sistema operativo que me ofrecía eran Rocky Linux o AlmaLinux.

Y ahí estuvo el detalle. Para MxOS, tener CentOS Stream 10 es un requerimiento a huevo. Así que, en lugar de ponerle peros a la donación, me puse a investigar cómo cambiar el alma de esos servidores. Al final, encontré el caminito para convertir AlmaLinux 10 a CentOS Stream 10 de volada.

#!/usr/bin/bash

# download almalinux release, repos and gpg-keys rpms
# just in case
dnf download almalinux-{release,repos,gpg-keys}

# install cs10's repos and gpg keys
dnf -y install \
     https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/Packages/centos-gpg-keys-10.0-23.el10.noarch.rpm \
     https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/Packages/centos-stream-repos-10.0-23.el10.noarch.rpm

# remove the almalinux files
rpm -e --nodeps almalinux-release almalinux-repos almalinux-gpg-keys

# install the cs10 release
dnf -y install \
     https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/Packages/centos-stream-release-10.0-23.el10.noarch.rpm

# sync
dnf -y distrosync --allowerasing

# fix SELinux labels
fixfiles onboot

# reboot
reboot

17 Jun 2026 10:10pm GMT

Earlier this week, curl project lead Daniel Stenberg announced the "curl summer of bliss". For just over a month, the maintainers will be taking a break. This includes not accepting any vulnerability reports. This is a good thing.

Most open source software relies in part or in total on the work of volunteers. Nothing can cause burnout quite like never getting a break. Even when someone is being paid to maintain software, they still need some time away. Taking time off is an investment in the long-term sustainability of the project.

"But this is bad for security!" you say. Yes, some vulnerabilities may go unaddressed. You get what you pay for sometimes. Stenberg made clear in his post that people with support contracts will still receive their agreed level of service. If the security of the project is important enough to you, there's something you can do about it. curl has seen a large increase in security reports this year. If a month off buys extra years of maintenance, that seems like a good trade.

It's easy for open source contributors to get wrapped up in the project. It becomes part of their identity and they sometimes feel like the project couldn't run without them. In some cases, that's true. But we're all still people and we need time to regroup. If you find yourself overwhelmed, you can take a break.

This post's featured photo by David Lezcano on Unsplash.

The post Taking a break is good appeared first on Duck Alignment Academy.

17 Jun 2026 12:00pm GMT

If you've ever needed to install Fedora Linux on a headless server, a Raspberry Pi, or any machine without a monitor attached, you've probably reached for VNC or RDP. They work - but as the installer moves to a web-based interface, there's a new opportunity to do something more native to that model. We're building it, and we want your input before we go too far down a path that's hard to reverse.

Why This Is Happening

The Anaconda installer's Web UI first landed in Fedora Linux 42 Workstation and was extended to all Live spins in Fedora Linux 43. It's a full graphical installer built on Cockpit tooling and using PatternFly widgets. The GUI is rendered in a fullscreen browser window - but until now, that browser had to be running on the same machine you're installing onto.

Here's the thing: VNC and RDP were built around the GTK interface. While RDP could technically work with the Web UI too (it operates at the display level), a remote browser is a much better fit - orders of magnitude less data and much lower UI latency. As the Web UI becomes the primary installer interface across Fedora Linux editions, it needs its own native remote access story.

On top of that, there are two more forces pushing in the same direction.

As browsers move toward Flatpak packaging - already the reality for atomic desktops and derivatives like Bazzite - remote installation opens an opportunity for shipping focused, smaller boot images that don't need to bundle a local browser at all. A lightweight ISO aimed at headless and network install scenarios, where the assumption is that you're connecting from another machine.

And once you have a browser-rendered installer, serving it to a remote browser is the natural next step anyway. A headless ARM SBC doesn't need to run a GPU-accelerated browser locally just to show you a disk partitioning screen. Your laptop can do that for it.

What It Actually Is

The concept is pretty straightforward: Anaconda's Web UI, already built on Cockpit, gets served over HTTPS. You point a browser at the machine you're installing, authenticate with a PIN, and you're controlling the installation remotely. No VNC client, no RDP client, no X forwarding. Just a browser.

If you've used Cockpit to manage a server, you already have a feel for the experience. The difference is that the machine you're connecting to is mid-install, not running a full OS.

Use Cases

The ones we've talked through most:

Headless servers - You're installing onto a server in a rack with no attached display. You expose the Web UI over the network and control everything from your workstation.

Lightweight ARM SBCs - Devices like Raspberry Pi have limited resources. With remote rendering, the Pi just runs the installer backend; all the UI rendering happens on whatever machine you're connecting from.

Remote monitoring - Even if you're not fully headless, being able to watch an installation from another machine is genuinely useful. Kick off a server install, go make coffee, check progress from your laptop.

The Design Decisions So Far

We've had some meaty discussions about how this should work, and a few things are now settled.

Authentication: You set a PIN through kickstart or boot options, and type it into the browser login page. Same pattern as VNC and RDP - the user provides the password, not the system.

TLS with self-signed certificates: The connection is encrypted, but the certificate is generated on the fly at boot. That means your browser will show the "this certificate isn't trusted" warning. We've accepted this tradeoff - shipping a private key on installation media is a security risk, and the IP address isn't known ahead of time, so standard PKI doesn't really apply. For environments that need proper certificates (say, a university deploying at scale), Image Builder is likely the right path to embed custom certs. That's a later problem.

Single connection only: Only one browser session can connect at a time. Two concurrent sessions could genuinely conflict - one session starting installation while another changes the storage configuration. So: one connection, full stop.

Reconnection behavior: If you disconnect and reconnect, what happens depends on where the installation was. Before the review screen - the point of no return - you start from step one. After the review screen (installation actually running), you land on the progress view. Simple two-state model, covers the critical cases.

Config isolation and port: All Cockpit configuration specific to remote installation lives in /etc/anaconda/cockpit/, not the default Cockpit paths - otherwise the config could leak into the installed system. We're leaning toward port 443 by default so you can just point your browser at the machine's IP without specifying a port, but the port will also be configurable.

How This Compares to VNC and RDP

VNC has been around in Anaconda for years; RDP support was added more recently. Both work by screen-sharing the GTK interface. Technically, RDP could work with the Web UI too - it operates at the display level, scraping pixels from the screen. But a remote browser is simply better: you send orders of magnitude less data and get much lower UI latency compared to streaming a full desktop.

Beyond performance, there are practical advantages. No client is required - any modern browser works. No VNC viewer to install, no RDP client to configure, no protocol quirks across platforms. And it's the same Web UI we're already actively developing, so features and fixes automatically benefit the remote experience. With VNC or RDP, you're screen-sharing a separate GTK codebase - a separate maintenance burden.

VNC and RDP aren't going away for now - they still work with the GTK legacy interface. But as the Web UI becomes the default across more Fedora Linux editions, browser-based remote access is where the investment goes.

Where We Are Right Now

This is a developer preview. Here's what's working:

• Custom login page with PIN-based authentication
• Separate socket-activated systemd unit for auth (clean separation from the main Cockpit process)
• Session cookies that survive tab closes, require re-login on browser close
• Cockpit config in an isolated, anaconda-owned path

Here's what's still open:

• Single-connection enforcement (this will likely require close collaboration with the Cockpit team)
• Backend detection of whether installation is already running (this is needed for proper reconnection behavior)

If you want to see the PoC in action, there's a draft PR at rhinstaller/anaconda-webui#1274 with the authentication setup - custom login page, pin-based auth script, socket-activated systemd units, and the Cockpit config override. To try it yourself, clone the PR branch, build an updates image, and boot it with virt-install:

git clone -b poc-remote https://github.com/bruno-fs/anaconda-webui.git
cd anaconda-webui
make create-updates.img

virt-install \
  --name anaconda-remote-test \
  --ram 4096 \
  --vcpus 2 \
  --disk size=20 \
  --location /path/to/Fedora-Everything-netinst-x86_64-Rawhide.iso \
  --extra-arg "inst.updates=http://your-host:port/updates.img" \
  --extra-arg "inst.webui.remote"

This is a proof of concept, not production-ready code. The PIN is hardcoded to 1234, there's no TLS, and single-connection enforcement isn't in place yet. Don't use this for real installations - it's meant to show the direction and let you poke at the approach. Once the installer boots, point a browser at the VM's IP and enter 1234 on the login page. It's rough, but it runs.

What We Want to Hear From You

We're sharing this now because some of these decisions are hard to unwind once the feature ships, and community input is more useful now than after the fact. A few things we're genuinely thinking about:

Remote installation is opt-in - you enable it through boot options or kickstart. But here's a question we're genuinely considering: should we ship a lightweight boot ISO without a local browser, with remote installation enabled by default? A minimal image aimed at headless and network install scenarios, where the assumption is that you're connecting from another machine. Would that be useful to you? And if you're using VNC or RDP for remote installation today, would this replace them? What would it need to do that it doesn't yet?

Come talk to us on Matrix (#anaconda:fedoraproject.org), or leave a comment on this article. You can also follow the work on the anaconda-webui GitHub repo. We're looking forward to hearing from you.

17 Jun 2026 8:00am GMT

17 Jun 2026 12:00am GMT

At the Flock 2026 Birds of a Feather session, poetically named FFFwF (or, for us lazy people, Forging Fedora's Future with Forgejo), we discussed the current state of our migration effort to the new forge. I asked the obligatory question: Who still has things on pagure.io?!

A few brave contributors raised their hands, some with an uneasy look in their eyes. Miro swiftly pointed out that everybody is affected by one particular repository; looking at you, `fedora-scm-requests`. Luckily, the RelEng folks have it in their sights. Sure, there are a few other repos lying around the old faithful, but it is time for the Fedora Project to move on and embrace the Forge.

Our new home is currently running on the LTS branch in v15.0.2. We are going to stick with it in production, and our next LTS upgrade will be to v19.

What is going to happen next?

Pagure itself as a project is hosted on pagure.io, and that service is going to be decommissioned at the end of July 2026. What does that mean for you? Well, that depends on when you are reading this.

If you just came back from Flock 2026 and you still have active repositories on pagure.io, here is what you need to do:

• Check out the existing organizations in the Forge. If your project fits into any of the existing ones, ask its owners for a migration.

• If it doesn't fit, open a ticket with the forge team, and we will help you decide the best path forward.

Some of us have commits in projects that point back to pagure.io. Don't worry, we are not going to break your links, for foreseeable future. We will explore options for implementing redirects so your historical links successfully point to their current locations.

The best way to handle the transition after your move, right now, is to inform your users about your new home. Add a BIG BOLD ANNOUNCEMENT to your README, close all open issues, and create a single pinned issue with your migration announcement.

Note: Do not expect to be able to log in to pagure.io after July 2026.

Wait… and what about `dist-git`?

Well, that is the next target in the scopes of the Forge team. As I showed you in the room, we have 11 Features that define the transition. The biggest task at hand is a bit more sneaky. We are missing multiple enhancements to the upstream project that will require a lot of coordination and Go code. So, if you find yourself in possession of spare cycles and a particular need to help us make it better and faster, Forgejo is waiting for you!

A road-map with all the tasks for the move will land in the Forge soon. (See resource list below.)

Important Links & Resources

• Check out the new home: Browse existing organizations on the new Fedora Forge
• Want to write some Go? Contribute to the upstream Forgejo project.
• Track our progress: Migration roadmap will be posted here soon

AI Disclaimer: Grammar and formatting were done with the help of robots; all the original brain-farts are my own.

16 Jun 2026 2:59pm GMT

16 Jun 2026 2:50pm GMT

Introduction

Hi, I'm Aman, a software developer and open-source enthusiast who enjoys backend development, APIs, and building tools that are useful to others.

I recently started my Outreachy internship with the Fedora community, and this is my first blog as an intern. In this post, I want to share what my first two weeks have been like, what I've learned so far, and what I'm looking forward to in the next phase of the internship.

I'm working on the Fedora Release Schedule Planner API, a project focused on improving Fedora's release planning workflow by moving away from older XML-heavy processes and strengthening the current FastAPI-based API through better tests, authentication, and infrastructure integration.

About the Fedora Community

Fedora is a global open-source community behind Fedora Linux and many related projects. People contribute in many areas, including packaging, infrastructure, design, documentation, testing, and release engineering.

One thing I've enjoyed learning about Fedora is its Four Foundations: Freedom, Friends, Features, and First. These values reflect Fedora's focus on free and open-source software, community, innovation, and adopting new technologies early.

What I like about Fedora is that it is not only about writing code. Communication, documentation, reviews, and helping new contributors are also important parts of the community.

Through this internship, I'm also getting a better understanding of Fedora's release process and how different contributors work together to improve the tools used by the community.

About My Project

My Outreachy project is Enhancing the Fedora Release Schedule Planner API.

Fedora's traditional release planning workflow relied heavily on manually edited XML files, which made the process difficult for newcomers, harder to scale, and less connected to modern tooling.

The Fedora Release Schedule Planner API is a modern FastAPI-based project hosted on Codeberg. It has already moved from Flask to a modular FastAPI architecture, uses Pydantic for data validation, provides auto-generated Swagger documentation, and relies on Forgejo Actions for CI/CD testing.

The goal of my internship is to help make this API more production-ready. My work will focus on improving the test suite, strengthening CI reliability, adding secure authentication with OpenID Connect, integrating the API with Fedora infrastructure data, and preparing it for deployment.

Learning More About the Community

I had already started contributing to the Fedora Release Schedule Planner API during the Outreachy contribution period. During that time, I joined the project's Matrix chat, went through issues and pull requests, and became familiar with the basic project structure.

So, during the first two weeks of the internship, my focus was more on understanding the project in depth. I followed discussions in the Matrix chat, worked through issue and pull request conversations, and learned how mentors and maintainers review changes.

We also have a weekly Google Meet call with the mentors. These calls are helpful for discussing progress, asking questions, and understanding what to focus on next.

Alongside exploring the codebase, I spent time reading Fedora documentation and project-related resources to better understand the release planning workflow.

I also explored the FastAPI codebase, tests, CI setup, and previous pull requests more closely. This helped me understand how tools like Pydantic, Swagger documentation, and Forgejo Actions are being used in the project.

Challenges and Wins

One of my biggest challenges in the first two weeks was understanding the codebase beyond its basic structure. During the contribution period, I had already become familiar with the main parts of the project, but during the internship, I started understanding how different layers work together, including API routes, database models, Pydantic schemas, services, templates, and tests.

Another challenge was making sure my changes did not affect existing behavior. I had to run tests, check formatting, and verify things locally before updating a pull request.

My biggest win was becoming more confident with the project workflow. I was able to work on issues, raise pull requests, respond to review feedback, and understand the expectations around code quality and maintainability.

I also became more comfortable with the tools used in the project, including FastAPI, SQLAlchemy, Pydantic, Jinja2, HTMX, tests, and CI checks.

A small win for me was getting some of my pull requests merged. For example, PR #425 and PR #427 helped me understand the review process better and gave me more confidence while working on the project.

Plans for the Next Month

In the next month, I want to continue building on the work from the first few weeks. Currently, we are focusing on fixing UI-related issues, improving the code structure, and aligning the codebase with the project's expected structure.

Along with that, I want to keep improving the test suite and make sure the API works correctly with the current FastAPI and Pydantic structure.

I also want to start preparing for the authentication part of the project. Since OpenID Connect is an important goal of this internship, I plan to spend time understanding how Fedora authentication works and how it can fit into the Release Schedule Planner API.

After that, I want to gradually learn more about how this API can connect with Fedora infrastructure data. This is important because the long-term goal of the project is to move away from the older XML-based workflow and make the release planning process more modern and maintainable.

Conclusion

These first two weeks have helped me understand the project better. I now have a clearer understanding of the Fedora community, the Release Schedule Planner API, and how people collaborate in open source.

I still have many things to learn, but I feel more comfortable with the project now than I did at the beginning of the internship.

I am thankful to Outreachy, Fedora, and my mentors for this opportunity, and I am looking forward to continuing the work in the coming weeks.

PS: Cover image generated with the help of an AI tool.

The post From Contributor to Outreachy Intern: My Fedora Journey Begins appeared first on Fedora Community Blog.

16 Jun 2026 12:00pm GMT

15 Jun 2026 6:55pm GMT

AI coding agents such as Claude code or Codex get more capable every month. This is great for productivity, but approving all commands gets annoying really quickly. On the other hand, allowing agents to run any command on your work machine is not a great idea. They are really good at exploring your production cluster using kubectl or running remote commands at your production servers over SSH.

Fortunately, Linux distributions come with plenty of options for process isolation. You can run agents as a completely different user, in a container, or in a VM. This article shows how to use microVMs to run coding agents.

Security concerns

Running AI agents in unattended mode is like running untrusted code. Companies behind these agents, such as Anthropic or Google, are not trying to steal credentials, but people keep coming up with new attack vectors like Slopsquatting or prompt injections virtually anywhere.

The coding agents themselves ship with built-in mitigations that try to refuse prompt injections as described, for example, here.

Lightweight sandboxing technologies are another layer of defense in coding agents. On Linux, bwrap is one of the possible implementations. This raises the bar, yet sandbox escapes are still a problem. Take a look at CVE-2026-39861 as an example of multi-platform sandbox escape.

You could use containers to isolate the agent in their own namespace, but they still share the host kernel. Some of the the recent kernel vulnerabilities resulted in privilege escalation (switching from regular user to root) suggesting that containers are not enough as a security boundary.

In the rest of this article, I describe how to use microVMs to easily sandbox coding agents on your Fedora Linux.

Exploring microVMs

First of all, let's take a look at what microVMs are. Just like any VM, they have their own kernel, one per each microVM. Compared to traditional VMs they start in very short time (hundreds of milliseconds) but don't offer all the features of full VMs.

This article explains usage of krun runtime for podman. This approach offers the same well-known workflow as containers, but simply runs every container as a microVM.

Start by installing the runtime:

dnf install crun-krun

To run a microVM, simply run podman with -runtime=krun in your terminal:

podman run --runtime=krun --rm -it fedora:44 /bin/bash

Things to watch out for

A microVM is not a regular container, so a few things might behave differently. First, allocate enough CPU and RAM with krun annotations. The defaults are too small and might result in OOM (Out Of Memory) kills. Second, make sure you have libkrun version >= 1.8. Older versions have a bug which prevents you from pressing Enter in your coding agent. Third, the microVM ignores the USER set in the Dockerfile and always boots as root. Either switch to the correct user manually or put the switch into an entrypoint script.

Case study: sandboxing Claude Code for a Python project

This section outlines a simple setup for a Python project managed by uv. It uses podman-compose to mount the project into the microVM. Compared to containers, this podman compose needs additional annotations for UID/GID translation, SELinux labeling, and HW resources. The final setup is very similar to what you would need for containers.

To install podman compose from official Fedora repositories, run:

dnf install podman-compose

The setup has 3 parts:

• Dockerfile
• docker-compose.yaml
• entrypoint.sh

Dockerfile

As mentioned above, podman with krun runtime still runs containers, but spawns each of them in a microVM. This example container includes uv package manager, claude code and a few additional RPM packages. Define your own container based on your project dependencies and programming language.

Make sure to create an unprivileged user and use it for running the agent.

FROM fedora:44

ARG HOST_UID=1000
ARG HOST_GID=1000

# Create group and user matching host UID/GID
RUN groupadd -g ${HOST_GID} appuser && \
    useradd -u ${HOST_UID} -g ${HOST_GID} -m appuser

RUN mkdir -p /venv && chown appuser:appuser /venv
RUN mkdir -p /home/appuser/.claude && chown appuser:appuser /home/appuser/.claude

USER appuser

# Rarely-changing tooling. Kept above the dnf layer so editing the RPM list
# below does not invalidate (and re-run) these installs.
RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
    curl -fsSL https://claude.ai/install.sh | bash
USER root

# Frequently-changing RPMs. Kept last so adding a package only rebuilds from here down.
RUN dnf install git make vim free libpq-devel python3-devel gcc -y && \
    dnf clean all

COPY --chown=appuser entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER appuser
WORKDIR /app

# This is needed because entrypoint does not have .local/bin in the PATH
ENV PATH="/home/appuser/.local/bin:$PATH"
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/bin/bash"]

docker-compose.yaml

The compose file defines how to mount the project directory into the microVM. This is where most of the magic happens, because podman needs to translate UID/GID and manage SELinux labels, otherwise the files would not be accessible inside of the microVM or they would end up being owned by a different user.

services:
  claude:
    container_name: project-name-claude
    annotations:
      run.oci.handler: krun
      krun.ram_mib: "4096"
      krun.cpus: "4"
    user: "${HOST_UID}:${HOST_GID}"
    userns_mode: keep-id  # optional, for rootless host
    build:
      context: .
      args:
        HOST_UID: "${HOST_UID}"  # use UID and GID from the host so that files created in the container have correct permissions
        HOST_GID: "${HOST_GID}"
    volumes:
      - ../:/app:U,z  # bind mount your project
      - project-name-venv-cache:/venv:U,z
      - claude-config:/home/appuser/.claude:U,z  # persistent claude credentials/config
    working_dir: /app
    stdin_open: true
    tty: true
    environment:
      - CLAUDE_CONFIG_DIR=/home/appuser/.claude
      - UV_LINK_MODE=copy
      - UV_PROJECT_ENVIRONMENT=/venv/env  # This is inside the cached volume
      - UV_PYTHON_INSTALL_DIR=/venv/python  # So that uv-managed python installations are not in home but cached in /venv
      - TERM=xterm-256color
      - COLORTERM=truecolor

volumes:
  project-name-venv-cache:
  claude-config:
    external: true
    name: claude-config

There are 3 key parts:

• annotations - these select krun as a runtime and specify HW requirements
• user and userns_mode - this tells podman to translate UID/GID so that the files created in the microVM end up owned by your user on the host
• volume labels - z tells podman to relabel the files with a shared SELinux label. Otherwise SELinux would prevent the process inside the microVM from touching the files in the volume. U tells podman to recursively chown all files.

entrypoint.sh

The entrypoint creates a virtual environment for the Python project, because we don't want dynamic dependencies baked into the container image. It also runs the switch from root to regular user because podman with krun runtime ignores the USER directive from the container.

#!/bin/bash
set -e

echo "Sandbox started as user: $(id -un) in directory: $(pwd)"

if [ "$(id -un)" != "appuser" ]; then
  runuser -u appuser -- uv sync
  echo "Running ${@} as appuser"
  exec runuser -u appuser -- "$@"
fi

uv sync
exec "$@"

Run the setup

First, build the container:

$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml build
STEP 1/18: FROM fedora:44
...
Successfully tagged localhost/agent-sandbox_claude:latest

Then create the external volume and run the claude container interactively:

$ podman volume create claude-config
$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml run --rm claude
Sandbox started as user: root in directory: /app
Resolved 3 packages in 6ms
Checked 3 packages in 1ms
Running /bin/bash as appuser
tty: ttyname error: Inappropriate ioctl for device
[appuser@3bd1234b9a77 app]$

You can now check that the kernel is different by running uname -a inside of the microVM.

Putting it together: single script to create the whole setup

Creating the same setup manually for every project is not the greatest user experience, but you can automate the setup using a simple script like this. It installs a new sbx command that wraps the setup described above into 3 simple command options: init, build, and run.

A word of caution - microVM is not a bulletproof boundary

A microVM raises the bar considerably, but it is not perfect isolation, and it would be irresponsible to present it as such. Take a look at the libkrun git repository to read more about the security model.

If you want to run software that might be dangerous, prefer using a full VM or even cloud VM.

Conclusion

MicroVMs seem like a sweet spot for running AI Agents. They provide a familiar workflow of containers, but the agents run on their own kernel behind a hypervisor. This article describes workflow based on podman and krun runtime because Fedora Linux ships both of them natively, but there are plenty of other options available for any platform (for example dockersandbox).

Note about AI usage: I wrote this article myself. I used Claude (Anthropic) to significantly refine the grammar, wording, and sentence structure; the technical content and all claims are my own and tested.

15 Jun 2026 8:00am GMT

The F44 election cycle has concluded. Below are the results. We are posting the results early this year as we are currently on the eve of Flock to Fedora 2026 and the results were ready. Thank you to all candidates and voters, and congratulations to the newly elected members!

Results

Council

Two Council seats were open this election. A total of 204 voters participated in this election.

FESCo

Five FESCo seats were open this election. A total of 199 voters participated in this election

Mindshare

Four Mindshare seats were open this election. A total of 154 voters participated in this election.

EPEL Steering Committee

Four EPEL Steering Committee seats were open this election. As the amount of interviews submitted equaled the number of open seats, candidates who interviewed were automatically elected.

The post F44 Election Results appeared first on Fedora Community Blog.

13 Jun 2026 4:16pm GMT

Flock to Fedora is more than a conference - it's where the Fedora community comes alive. As part of the In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they're hoping for in Prague this June. This is one of those conversations.

In 2015, an 18-year-old student walked into his first Flock not knowing a single person. He was shy, a little overwhelmed, and had no idea what he was walking into. By the time he walked out, something had shifted. The community had been so genuinely welcoming, so warm and easy to fall into that he left not just curious about Fedora, but hungry to be part of it.

That student was Justin Wheeler. And Flock never really let him go.

What started as one conference became a thread running through his entire open source journey. First he became a Fedora Magazine author. Then editor-in-chief. And now, as Fedora Community Architect, he's the one standing on stage at the opening and closing looking out at the very kind of room that once changed his life helping shape the event that shaped him.

He'll be the first to admit it's a lot. "It's way more intense and hard work than I ever could have realized," he says, with genuine respect for everyone who built Flock before him. But that experience of once being the nervous newcomer gives him something no job description could have: an instinct for why people show up and what makes it matter.

For Justin, the answer has always been the hallway track. Not the sessions, the spaces in between them. The moment you bump into the exact person you need to talk to. The lunch conversation that turns into a collaboration. The game night and candy swap where the ice finally breaks and people stop being usernames and start being friends. "It's the relationships we get to strengthen and build," he says, "that make us so much more effective in everything we do the rest of the year."

That's also what data can't capture and Justin thinks about this a lot as part of the Data Working Group, where he works alongside Michael Winters and Robert Wright to understand community health. Numbers can tell you a lot. But they can't show you a first-timer lighting up when they realise they belong here. They can't measure the moment the community becomes real.

His advice for anyone walking into Flock for the first time? "Don't be shy. Leave your comfort zone a little. And definitely don't skip the social events." He says it like someone who knows exactly what it feels like to need that push and exactly what's waiting on the other side of it.

Flock to Fedora 2026 takes place June 14-16 in Prague. Registration is at capacity but you can join the waitlist. Can't make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

12 Jun 2026 3:53pm GMT

11 Jun 2026 10:00pm GMT

UEFI Secure Boot keys, used to sign the first stage boot loader, are expiring in June 2026 (this month!) But that only means that Microsoft can no longer sign with them. Machines, both bare metal and virtual, will continue to boot long after June is over as long as the current public keys are not removed from the firmware database or revoked via the dbx database. In the meantime, Fedora Rawhide (f45) already contains a first stage boot loader that is signed by multiple keys for maximal compatibility. So there is no need to panic, but action is recommended.

Secure Boot basics

UEFI Secure Boot is a security feature which ensures only trusted (signed) applications run during a computer's boot up process. This applies to the boot loaders, the operating system kernel, and the kernel modules. Trust is established using asymmetric cryptography. Tested algorithms, like RSA or ECDSA, are used to create asymmetric key pairs. The private key is used to sign the application. A totally different but complementary public key is used to verify the application. The private key is kept secret while the public key is available to anyone who wants to run the application. UEFI Secure Boot is only available for machines that run UEFI firmware, and for Fedora, the key expiration only applies to the x86_64 architecture (Intel, AMD), and to those who have Secure Boot enabled.

The root of trust for Secure Boot is in the firmware. Hardware manufacturers add trusted Secure Boot public keys to their devices' Secure Boot firmware database (db). Firmware for virtualization, known as edk2-ovmf, is built with similar trusted public keys. In order to simplify the process, there is a central signing authority which signs the first stage boot loader. This is the "shim" whose public key is enrolled pretty much everywhere, and that is Microsoft. Microsoft first started signing shim with their 2011 UEFI Third Party CA, but by the end of June they will no longer be able to do so. Since October 2025, Microsoft began signing with a new 2023 key as well. Once the 2011 key expires, new shims will only be signed with the 2023 key.

The OS maintains the rest of the Secure Boot chain. Fedora's shim embeds a Fedora Secure Boot public CA key. Private keys on Fedora's signing server are used to sign the next stage boot loader (grub2), the kernel, and any other applications that need to run during the boot process (like fwupd for firmware updates or unified kernel images- UKIs)

When the kernel is built, kernel modules are signed using an ephemeral key. Only signed kernel modules can be loaded when Secure Boot is enabled.

Action Recommended

The fact is that you don't really have to do anything about any of this right now. Your computer will continue to boot. New installations of both older and new OSes will continue to be possible.

BUT, we recommend updating your Secure Boot database if and when an update is available. The next deliverable shim update can only be signed by the 2023 key and it is best to be prepared. While there are no known exploitable security vulnerabilities in shim at this time, new ones may be found next month or next year. Below are some commands that will help you determine what state your computer is in, and how to make the correct updates.

How to tell if you have UEFI or legacy BIOS

The presence of the /sys/firmware/efi directory is the clearest way to check whether you are running UEFI firmware or legacy BIOS. The following command will print "BIOS" if the efi directory does not exist:

$ [[ -d /sys/firmware/efi ]] || echo BIOS

How to check if Secure Boot is enabled

$ mokutil --sb-state
SecureBoot enabled

The Secure Boot state may be "enabled", "disabled", or the machine may be in "Setup Mode", which means there are no Secure Boot keys enrolled in firmware.

How to identify which keys are in the firmware db

$ mokutil --db --short
580a6f4cc4 Microsoft Windows Production PCA 2011
45a0fa3260 Windows UEFI CA 2023
46def63b5c Microsoft Corporation UEFI CA 2011
b5eeb4a670 Microsoft UEFI CA 2023

This output is from a VM, and as you can see, it already contains the 2011 and 2023 public keys. Your laptop or desktop will also show other database keys from the manufacturer.

How to update the firmware db

Enable and use fwupd to get your updates from the Linux Vendor Firmware Service (LVFS):

$ sudo fwupdmgr update

If you have an HP or Fujitsu machine, the update will be available soon, after you have updated your firmware. Use either the above command, or the vendor-recommended command at that time.

How to check which key(s) signed the shim

$ sudo dnf install pesign -y
$ sudo pesign -S -i /boot/efi/EFI/fedora/shimx64.efi
----------------------------------------------
certificate address is 0x7f3fffc11410
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
----------------------------------------------
certificate address is 0x7f3fffc139e0
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft UEFI CA 2023 signer
No signer email address.
No signing time included.
There were certs or crls included.
-----------------------------------------------

The output shown here is from the dual-signed Fedora Rawhide (F45) shim. If Rawhide is not installed, the shim will only be signed with the first key, which is the 2011 key.

You can use the same pesign command to examine grub2 (/boot/efi/EFI/fedora/grubx64.efi) and the kernel (/boot/vmlinuz-…).

What NOT to do

If a database update is not available for your system, contact your hardware manufacturer. Do not attempt to force an incompatible update. Do not update your database manually unless you know exactly what you are doing!

Do not remove or revoke the 2011 key. The 2011 key is not compromised, it is only expiring, so there is no need to remove it. Additionally, it was used to sign option ROMs, so removing it could render peripherals on your system inoperable. Likewise, adding the 2011 key to the firmware dbx database (the forbidden database) will affect option ROMs. This will stop the dual-signed shim from booting.

11 Jun 2026 8:00am GMT

11 Jun 2026 5:35am GMT

10 Jun 2026 1:00pm GMT