C-Kermit 11.0.506 was released on August 3, the first non beta version since 9.0.302 in 2011, and the project is now maintained as OpenKermit on GitHub. Kermit is the file transfer and terminal emulation software that has connected serial ports, modems and unglamorous industrial equipment since 1981, which makes this a forty five year old protocol getting its first real release in fifteen years. The new version adds IPv6, more than seventeen hundred test cases and continuous integration across Linux, macOS, FreeBSD and NetBSD. It also changes several defaults, which is the part that matters if you have scripts.
The short answer
C-Kermit 11.0.506 was released on August 3, maintained as OpenKermit on GitHub and dedicated to Frank da Cruz, who worked on Kermit from 1981 until his retirement from the project in 2025. The release adds IPv6 support, more than seventeen hundred test cases and continuous integration on Linux, macOS, FreeBSD and NetBSD. Several defaults changed, including file collision handling and automatic transfer mode. Invoking the binary as kermit9 or kermit10 restores the legacy behaviour.
Kermit is older than most of the people who will read this, and it is still the tool you reach for when the device on the other end of the cable was manufactured before Google existed and has no intention of speaking anything modern.
On August 3, C-Kermit 11.0.506 was released. It is the first non beta release since 9.0.302 in 2011, it is maintained on GitHub under the OpenKermit organisation, and it is dedicated to Frank da Cruz, who was involved with Kermit from its design at Columbia University in 1981 through to his retirement from the project in 2025.
Why a forty five year old protocol still ships
Kermit was built for links that fail. It has tunable packet sizes, sliding windows, and error detection and recovery designed on the assumption that the transport underneath is unreliable and possibly hostile. That was a description of a 1200 baud modem line in 1981. It is also a fair description of a serial console on an industrial controller reached through three adapters in a plant room today.
The reason it persists is not nostalgia. It is that the other end cannot be upgraded. Laboratory instruments, telecom gear, embedded boards, medical hardware, machine tools: equipment whose vendor is gone, whose firmware is frozen, and whose only management path is a serial port speaking a protocol that was standard when it was built. Kermit is the piece of software that still speaks it.
What is new
The functional headline is IPv6 support, which is not a small item for a program whose networking assumptions were formed in a different era.
The engineering headline is more interesting. The release ships a test suite with more than seventeen hundred cases and automated builds across Linux, macOS, FreeBSD and NetBSD. For a decades old C codebase that has been maintained largely by hand, that is the difference between a project that can accept contributions and one where every change is a gamble.
The correctness fixes read like an archaeology report. Packet size boundary handling, data corruption during protocol renegotiation, pseudoterminal problems on macOS, and support for filenames containing spaces, which had never been handled properly throughout. One reported bug in a strlen() call dated back to 1992. Despite everything added, the codebase excluding comments came out roughly 2600 lines smaller than the last 10.x beta.
The defaults are the upgrade risk
This is the part to plan around, because a script that silently behaves differently is worse than one that fails.
File collision handling moved from BACKUP to REJECT. An incoming file that would overwrite an existing one is now refused instead of being quietly renamed out of the way. MAIL and PRINT handling are off by default. Unrequested incoming files now prompt for confirmation rather than being accepted. Automatic transfer mode selection is disabled, because it could corrupt data. Variable evaluation behaviour also changed.
If you have automation that ships files onto or off devices, at least two of those are likely to matter to you, and the collision change is the one most likely to turn a working job into a job that reports success while transferring nothing.
Our advice for anyone running it in anger
The release gives you a migration path, and we would use it.
Invoking the binary as kermit9 or kermit10 restores the corresponding legacy behaviour. That lets you separate two things that should never be done at once: upgrading the binary, and auditing every script that depends on it. Install version 11, repoint existing automation at the legacy invocation name, confirm nothing changed, then migrate scripts to the new defaults deliberately, one at a time, with the collision setting checked explicitly rather than inherited.
We would not treat the legacy names as a permanent home. They exist to make the upgrade survivable, not to freeze you at 2011 forever. But given that the last release many of these deployments have seen is fifteen years old, a staged path is worth more than a clean one.
There is something quietly encouraging about this release. A piece of infrastructure that a lot of important, boring machinery depends on had gone fifteen years without a stable version and was one retirement away from being unmaintained. It now has a test suite, CI on four platforms, a public repository and a smaller codebase than before. That is a better position than it has been in for a very long time.
Sources and further reading
- C-Kermit 11.0.506 release notes, OpenKermit on GitHub, August 3, 2026
- C-Kermit 11 released, LWN.net
- Celebrating 45 years of Kermit with the first new C-Kermit release in 15 years, The Changelog
- The OpenKermit repository
Frequently asked questions
Does anyone still use Kermit in 2026?
More people than you would guess, and almost none of them talk about it. Kermit survives where the other end of the wire cannot be changed: laboratory instruments, industrial controllers, telecom equipment, embedded boards whose only management interface is a serial console, medical and scientific hardware bought in the 1990s and still doing its job. The protocol was designed for hostile links, with tunable packet sizes, sliding windows and error recovery that predate the assumption of a reliable transport. If you have ever needed to move a file to a device over a flaky RS-232 link at three in the morning, you already know why it still exists.
What actually changed between 9.0 and 11?
The headline items are IPv6 support, a real test suite with more than seventeen hundred cases and automated builds across Linux, macOS, FreeBSD and NetBSD. Alongside that there is a long list of correctness fixes: packet size boundary handling, data corruption during renegotiation, pseudoterminal problems on macOS, and proper handling of filenames containing spaces, which is the kind of gap that seems impossible in software this old until you remember when it was written. One reported bug in a strlen() call dated back to 1992. The codebase excluding comments also came out roughly 2600 lines smaller than the last 10.x beta, despite the added features.
Which defaults changed, and will they break my scripts?
They can, and this is the section to read before upgrading anything automated. File collision handling changed from BACKUP to REJECT, so an incoming file that would overwrite an existing one is now refused rather than quietly renamed. MAIL and PRINT handling are disabled by default. Unrequested incoming files now prompt for confirmation. Automatic transfer mode selection is off, because it could corrupt data. Variable evaluation behaviour also changed. Any script that relied on the old collision behaviour or on autotransfer will behave differently, and it will do so silently in the sense that Kermit is doing exactly what you now told it to do.
Is there a way to keep the old behaviour while I fix my scripts?
Yes, and it is the detail we would highlight to anyone running Kermit in production. The release provides kermit9 and kermit10 invocation names that restore the corresponding legacy behaviour. That gives you a migration path rather than a cliff: point existing automation at kermit9, upgrade the binary, confirm nothing broke, then move scripts to the new defaults one at a time. We would not leave anything on the legacy name permanently, but as a way to decouple the upgrade from the script audit it is exactly the right affordance.
Who maintains it now that Frank da Cruz has retired?
The project has moved to a community maintained repository, OpenKermit on GitHub, and the 11.0 release is dedicated to Frank da Cruz. He was involved with Kermit from its design at Columbia University in 1981 through to his retirement from the project in 2025, which is forty four years on one piece of software. When Kermit left Columbia he volunteered to keep maintaining it, and continued to produce alpha and beta releases through that period. The 10.x line never reached a final release, which is why version 11 follows 9.0.302 directly.