Category: Fedora

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!

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.

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.

Jaroslav Reznik has been part of Fedora longer than most people remember. This goes all the way back to Red Hat Linux 5, before Fedora was even known as Fedora. After a brief detour to another distro, he joined the KDE SIG days and went on to build a long career in Red Hat’s Program Management team. But it was the EU Cyber Resilience Act (CRA) that brought him back to the Fedora community.

The moment that changed everything? A scene at FUDCon North America in 2009 watching Fedora’s Program Manager command what looked like a sci-fi control room, scheduling Fedora 13. Jaroslav looked at that and thought: I want that job. Years later, he got it.

On the CRA, Jaroslav is clear and passionate. The regulation is the first to formally acknowledge the existence of open source software in legislation. Thanks to an enormous community effort, it’s actually open-source friendly. Non-commercialised community projects are fully exempt. For a project like Fedora, the concept of open-source stewards formally recognised in the regulation opens up a powerful new model for governance.

The program management team is working to build a stewardship governance model around Fedora. They are making it a welcoming place for anyone who wants to support the project. They are clear about what stewardship should and shouldn’t be: it’s not about monetizing open source or adding burdens, it’s about helping the community raise the bar for security together.

Flock holds a special place for Jaroslav; he co-organised the very first Flock held in Prague back in 2014. Now, more than ten years later, he is returning to Prague for Flock 2026 with Roman Zhukov to not only talk about the CRA but run a hands-on workshop on it. His message is simple: you can’t do things from behind a desk.

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!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Yes, the Fedora 43 upgrade brought an interesting revelation for all Outlook users—one that Microsoft is unlikely to be thrilled about. Outlook was not encrypting email connections, even though SSL/TLS was clearly enabled in the account settings. It looks like, that bug dates back to at least Outlook 2007, which is the oldest Outlook version I was informed about.

Let us start with the beginning

Every six months, Fedora Servers require and upgrade to the next release version, as you all know This May we had to upgrade from 42 to 43 and in this upgrade, Dovecot POP/IMAP server switched to version 2.4.3. Dovecot did us all an unexpected favor, because it required a full rewrite of the used service config, because it’s not backwards compatible. This change introduced a new paradigm: PLAIN TEXT passwords are no longer allowed over unencrypted connections.

This is a major break with the oldest RFCs (i.e. RFC 1081) regarding POP3 behavior, but a good one IMHO. No one should still use unencrypted connections to any form of service on the internet when we have easy to use encryption protocols like STARTTLS (STLS) at hand in any major client.

The Day After

After the upgrade, “we” (admins & customers) did not even know about the now broken auth-mechanism. This came a day later when customers started to call the support line about rquesters popping up for them to enter their passwords again. This is a normal behavior if auth fails… and it failed hard

As all admins know, such upgrades will result in higher amounts of support calls. To my surprise it was all Outlook clients that called. The oldest version so far was Outlook 2007. We even had an old MACOS Outlook :-). They all had in common, that the mailbox prefs had “SSL/TLS” enabled, but used Port 110, which is the old cleartext port for POP3, where port 995 is the correct SSL port. A normal mailclient would change the port number to 995 as soon as you enable SSL/TLS encryption. This is because you can’t “speak” SSL on a non-ssl port, except if you choose STARTTLS. This starts as a cleartext connection, but upgrades itself to ssl-encrypted later.

“Look, there is something out there!”

Outlook did the worst move you can take as a security enhanced app. It silently ignored the choosen SSL option and used the unencrypted port 110 without any notice to the user. After our server upgrade, the following message popped up:

“-ERR [AUTH] Cleartext authentication disallowed on non -secure ( SSL/TLS ) connections.“ popped up if you tried to open your inbox. The server logs revealed it clearly: the user used a non-secure connection and got this message correctly. This never got noticed since the EU GDRP only states, that corporations and organisations need to protect their data via a transport encryption like TLS. Normal persons don’t need to do so.

Even some of the notable folks of Fedora did not use encryption, which I personally advise to change immediately. Having this in mind, who are we to judge if you encrypt your connection or not?

Really folks: use TLS encryption for your mailboxes!

You can easily check if TLS encryption is working. Send yourself an mail and open the mail headers, you will find lines like this:

Received: from bastion01.fedoraproject.org ([38.145.32.11] helo=bastion.fedoraproject.org)
by s113.resellerdesktop.de with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384
(Exim 4.99.2)
(envelope-from <updates@fedoraproject.org>)
…
Any good MTA ( Exim, Postfix, etc. ) will note if the connection was encrypted or not.

If you don’t see an encryption notice, you can use this command:

tcpdump -A -n -n port 110 or port 143 

in a root terminal and see if the unencrypted port is used for transport. If so, if it’s cleartext or if it’s using STLS.

So… THANKS Fedora 43 and Dovecot 2.4 … you revealed a 20 year old security bug in Outlook \o/

Disclaimer: It is possible that MS patched the Outlook UI in the past in a way that only old accounts are affected by this major fail. As Fedora users we had no Outlook available to test this

Source: https://marius.bloggt-in-braunschweig.de/2026/06/03/outlook-hat-emailverbindung-nicht-verschluesselt/