10 Nov 2026
Planet Debian
John Goerzen: The Large Project Bias of CVEs
I recently discovered some vulnerabilities in C-Kermit, one dating back to 1984. I tried to do the reasonable thing: create advisories with CVEs.
That turns out to be pretty difficult for a small independent project.
Large projects have a way to self-assign CVE IDs. They are their own CVE Numbering Authority (CNA). There is a massive list of CNAs. Just looking at the first page of results, I see everyone from Airbus to 9front (the niche Plan 9 OS). The OpenKermit project is not a CNA.
If you're a CNA, you can create and publish CVEs on your schedule. There is apparently no external review process. You can wait for months, or publish immediately.
If you're not a CNA, you have to find someone that is. The general ones that are CNAs appear to be Github and MITRE.
Since C-Kermit is hosted on Github, I thought I would go that route. I followed the documented procedure: created Github security advisories for C-Kermit, then clicked the request CVE button for each. The documentation states they will typically review within 72 hours.
It's been a week and a half and no sign of a review yet. Apparently the real review time is more than a month.
The other option for projects without a CNA is via MITRE. You have to use a strange and often broken web form, logging in with either Google or Gitlab. (It seems to be broken on Firefox). Then you submit your request and wait.
How long do you wait on MITRE? It seems it could be anywhere from a day to several months.
The first CVE I obtained for C-Kermit was CVE-2025-68920. At the time, I had not yet started the OpenKermit project. That issue was found and fixed in the context of my work maintaining C-Kermit for Debian, and Debian is a CNA.
These were discovered while wearing my "upstream C-Kermit maintainer" hat. I'm sure I could ask Debian for CVEs again, but that seems a bit cheating; not everyone that maintains a FLOSS project will have connections with a distro like I do.
There are a lot of components of a modern OS and Internet ecosystem that are small projects without a large institution behind them.
This bias towards large organizations when it comes to communicating security problems benefits nobody. It doesn't benefit users, and only serves to discourage timely communication. Not everyone is as persistent as I am, and when it is made so difficult to make announcements - which seem to go into a giant black hole - it's easy to say, "why bother?"
By Microsoft's own admission, they are under-funding their CVE process on Github (which may also be poorly-designed). They blame it on increasing load due to LLMs - a problem they helped create and predicted! Having a fiction about being able to communicate a security issue in a reasonable time is worse than not offering the path at all.
Linux was once a student's experiment. Let's not pretend that quality only matters from large projects.
10 Nov 2026 1:42pm GMT
Vasudev Kamath: Experiment: Debian Cloud/VM Images using mkosi
Debian's Cloud Images for various public cloud platforms and VM environments are built using a tool called debian-cloud-images, an in-house utility developed and maintained by the Debian Cloud Team.
What?
The debian-cloud-images tooling uses FAI (Fully Automatic Installation) to create custom VM images for public clouds like GCP, Azure, and AWS, along with the genericcloud class. I wanted to convert this into a fully declarative, mkosi-based image build where the entire image is described using INI-format configuration files, with only a few post-installation scripts to handle final customizations.
Why?
I've been working with various image customization formats for a long time. In my previous company, I used to build customized industrial PC distributions based purely on Debian using multistrap and a bunch of shell scripts to stitch together raw image creation, bootloader installation, etc. I've also done custom installs using debootstrap on my own laptop with systemd-boot as the bootloader, but that was mostly hand-crafted and not automated. Once I came across mkosi, I was impressed by how a single utility can do everything and churn out a fully usable image without extra glue scripts for partitioning and image creation. You still need a few scripts to finalize some parts of the installation (via postinst hooks), but those are very minimal.
So I decided: why not convert debian-cloud-images into mkosi's declarative format with a few architectural changes? My requirements were:
-
Btrfs as the root filesystem: Partly because I like it, but primarily for the ability to use transparent compression (zstd:1), subvolumes, and snapshots for atomic rollbacks when things go wrong.
-
systemd-boot and Unified Kernel Images (UKI): Primarily because systemd-boot is clean and minimal-exactly what a modern bootloader should be. Combining it with UKIs and UEFI Secure Boot is bliss compared to the complexity of the GRUB2 world.
Note: This intentionally drops legacy BIOS (MBR/CSM) partitioning support in favor of pure UEFI. Modern cloud platforms (AWS Nitro, Azure Gen2, GCP) support UEFI natively, and dropping BIOS allows shedding significant legacy bootloader baggage-though it does make these images unsuitable for older, non-UEFI hypervisors.
Implementation
Of course, the initial heavy lifting was done mostly using Antigravity (agy), along with debugging, tuning, and cleanup from my side. I pointed agy to a local copy of debian-cloud-images and laid out my requirements: preserve parity with the original packages and configurations, while enabling selective builds for each cloud via modular profiles. The resulting specification is documented here.
The repository also includes a verification script that audits functional parity against official images produced by debian-cloud-images (verifying packages, APT deb822 sources, and systemd services, while accounting for the switch to Btrfs and systemd-boot). Initial verification was performed for all Trixie profiles, and the parity report is published here.
I've also booted the genericcloud profile image under UEFI in a local VM to verify live bootability, bootctl status, network connectivity, and APT repository setup. This completes Phase 1 of the implementation. The remaining phases outlined in the specification include:
- Phase 2: Immutable Images with dm-verity: Configure Verity=hash in systemd-repart's 10-root.conf. Enable mkosi auto-signing for the verity root hash and pass the root hash into UKI kernel command lines automatically.
- Phase 3: Secure Boot & Signed UKIs: Integrate SecureBoot=yes with custom owner keys or ShimBootloader=signed using Microsoft Third-Party CA signed shim binaries.
- Phase 4: System Extensions (systemd-sysext): Decouple cloud vendor agents (AWS CLI, Azure waagent, GCP guest agent) into separate .raw system extensions. Maintain a single unified, signed base OS image across all cloud platforms.
- Phase 5: Btrfs Automated Rollbacks: Combine Btrfs @snapshots with systemd-boot snapshot boot entries for fail-safe OS upgrades.
Another advantage of this setup is that the same tooling can build images for physical laptops and bare-metal servers. For example, in an earlier post, I walked through live-booting with debootstrap and manually configuring systemd-boot for a custom UEFI installation. With mkosi, I can simply generate a customized image locally with UKIs ready to go, live-boot the target machine, and write the image directly to the root disk.
Conclusion
This experiment is an exploration of the power of mkosi; I haven't discussed adoption with the Debian Cloud Team yet. For now, this will continue as my pet project. While I won't be hosting pre-built binary images, anyone interested is welcome to clone the repository and build the images locally.
I will probably take some more time before tackling dm-verity images, as I want to understand the nuances thoroughly before experimenting with them. Until then, happy hacking! Please report any issues or suggestions on GitHub.
10 Nov 2026 7:00am GMT
09 Nov 2026
Planet Debian
Amin Bandali: EmacsConf 2026 community panel - my comments
This is a recollection of my comments from the EmacsConf 2026 community panel recording session this past weekend, where the panellists took turns answering the proposed questions, one minute per question per panellist.
In addition to the live Q&A session planned for Saturday 12 December 2026 during EmacsConf 2026, all Emacs users and community members are invited to share their thoughts on the panel questions or other questions before or after the conference.
https://emacsconf.org/2026/talks/community/
1. What made you start using Emacs, and what kept you using it?
I started using Emacs during my bachelor's studies. I actually learned about Vim first and was a Vim user, but I'd always found the configuration language (VimScript) a little bit clunky. Not long after, I discovered Emacs, and really loved reading and writing Emacs Lisp, so I stuck around.
In addition to reading and writing Elisp being fun and enjoyable for me, I love that Emacs has been a practical embodiment of software freedom, and I'm really fond of its surrounding culture of sharing freely. There's a lot to love and appreciate about Emacs, but as a practical personal example, I've been grateful for its excellent support for bidirectional text editing. It has empowered me to read and write in Persian, my mother tongue, with ease. (Persian has a right-to-left alphabet, like Arabic and Hebrew.)
2. What took you from using Emacs to actively contributing to the community - participating in forums, writing Elisp, organizing meetups, answering questions?
As I continued experimenting and writing bits and pieces of Elisp to scratch my own itches, I felt compelled to share them freely as a way of giving back to the community that gave me so much.
For me, the community and the people that make it up are the main deal. Emacs wouldn't be where it is and what it is today without its people, so besides programming contributions, I've tried to contribute in that area as well, for instance by reviving EmacsConf with Sacha Chua back in 2019.
3. How does Emacs show up for you in real life - colleagues, meetups, friends? How did those connections form?
I don't physically have people near me who use Emacs, but I've connected with many folks in our online communities, often starting with an email or IRC message. Some of those relationships started as acquaintanceship and were developed into true friendship over time, and I'm grateful to have had those friends with me.
4. If you know other software communities, what's one thing Emacs could learn from them?
I would encourage Emacs, our community, to focus on the people. We're living in particularly difficult times, with various kinds of hardships and uncertainty in our lives. Let's strive to treat each other with kindness, empathy, and mindfulness as we continue working together.
There are great examples of other free software communities whose members have banded together and are strengthening each other and their community, as well as cautionary ones where community members have been tiring and driving out their fellow members. We could learn valuable lessons from both in how to take care of our people and ourselves.
5. What's one concrete thing you wish existed in the Emacs community a year from now?
I echoed the sentiments of my fellow panellists Prot and Til about doing more of the same in terms of continuing to uphold the standards of excellence and perseverance. Also, drawing inspiration from what bashbunni said, to lower the barriers of entry for people, for example through organizing different kinds of events, and experimenting with ways to make people's lengthy, elaborate Emacs configurations more tangible and accessible to others, to share various workflows and demonstrate what's possible with Emacs.
I look forward to your thoughts on these and other community-related questions.
Take care, and so long for now.
09 Nov 2026 9:57pm GMT