Celebrating 45 Years of Kermit with the First New C-Kermit Release in 15 Years (and working with a decades-old C codebase)

1981 was a different time for computing. It was expensive (both hardware and software), and it was far from a given that machines from one vendor would be able to talk to those from another. In fact, Columbia University had just such a problem, so in 1981, Frank da Cruz and Bill Catchings designed a serial protocol they called Kermit. Because of the many quirks of the DEC-20 and IBM mainframes, the Kermit protocol was highly adaptable from the start: able to handle systems that had trouble processing more than 96 bytes of data at once, able to transfer 8-bit files over 7-bit links, able to translate between character sets (ASCII and EBCDIC then; now also various Unicodes), and of course, handling of error-prone serial links.

Kermit spread rapidly; by 1982, Kermit had been ported to MS-DOS and Unix. Eventually, C-Kermit (an implementation of Kermit in C) became the flagship Kermit. It gained TCP support, an interactive CLI, a powerful scripting language (with features from the shell, Lisp, and expect), and optimizations for today’s high-speed links, such as jumbo packets, sliding windows, and streaming modes. Along the way, Kermit flew on the International Space Station, ran data collection from sensors during hurricanes, and many other uses including postal systems, Boeing 787 manufacturing, and more.

Today, I use it as a powerful ssh wrapper (letting me easily transfer files through multiple nested ssh, sudo, su, etc. commands), a BBS client, to exchange data with me HP 48GX calculator, and so on. It’s also used today to transmit firmware updates to embedded devices. And, of course, anyone that works with vintage systems is likely to use Kermit at some point.

It wouldn’t be until the late 1990s that the TCP/IP stack was finally adopted by most OS vendors, establishing something of a common basis for communication. Of course, we assume this today. Though transferring large files between OSs (say, Linux, Windows, MacOS, Android, iPad, etc.) is still a challenge, even though they all speak TCP/IP! I find that the easiest way to get large files from two computers is to spin up Kermit (see ckwin for a Windows fork of C-Kermit) and just set up a TCP connection over the LAN. In fact, I added a new show interfaces command in C-Kermit 11, making it easy to see your system’s local IPs.

For most of its history, Columbia’s Kermit project was self-funded. Columbia charged for commercial use, which limited its inclusion in Linux distributions. In 2011, 30 years after its founding, Columbia canceled the Kermit Project and released C-Kermit as Open Source under a BSD license. Frank da Cruz, who had still been working with the Kermit project all those years, volunteered to continue maintaining Kermit outside Columbia, and continued development with alpha and beta releases through his retirement from the project in 2025.

I dive into this C codebase

As Debian maintainer of Kermit, I noticed some areas where it wasn’t matching modern expectations. One area was, not surprising for a project of its age, security. Another area was that its character set or line-ending conversions are usually not desired now; we are used to byte-identical binary transfers, and the defaults caused confusion and even some rare instances of data corruption. So I started making a few patches last year.

I’ve worked with old C codebases before, such as Varnish. I’ve generally hated it. You usually find a mix of bad and terrible practices, unclear memory management, and so forth.

But I’ve been living in the C-Kermit codebase for a few months now, and I enjoy it. Yes, this thing is still designed to build on VMS, OS/2, and with compilers that haven’t heard of ANSI — and those that require modern practices. (That em-dash was mine; I knew how to use them before LLMs existed and I’m not going to stop just because LLMs have copied people like me! No AI was used for this post.)

The there is an elegance in all of that. As I worked, I fixed a bunch more potential security issues, both with memory safety and with protecting against a malicious remote in roughly the same manner that some patches to scp did a few years back. I added IPv6 support, of course conditionally compiled because some systems C-Kermit builds on have never heard of IPv6 and never will. (And, of course, with fallback algorithms at runtime for systems that have IPv6 support but not IPv6 connectivity.)

I added unit tests and Python-based end-to-end tests, running nearly 2000 test cases in total. Along the way, I found and fixed a number of bugs going back decades. I learned about FIONREAD being broken on macOS, about NetBSD’s bugs in the pty driver, and fixed bugs in the Kermit protocol implementation itself. I added compatibility tests with the gkermit and ekermit (embedded) implementations, as well as the last full release, C-Kermit 9.0.302 from 2011 (which was difficult to get compiled on a modern system).

There is an extensive changelog describing all the improvements in C-Kermit 11.

C-Kermit development had never really used a VCS at any point, though Kermit veteran Jeffrey Altman imported historical releases into a Git repo, along with some patches that hadn’t made it into a release (which I also pulled in.) There was a lot of disabled code behind COMMENT, along with commentary describing why it was no longer used. With Git, we would now generally just remove the old code and explain why in a commit message. I went through and did so with a lot of it, meaning that, at last check, C-Kermit actually has fewer lines of code now than it used to.

Towards a new release

It became apparent pretty quickly that I was making more changes than would make sense as a Debian patch series. Not only that, but they would be more widely applicable to more than just Debian and Ubuntu users. As Linux and BSD distributions were running everything from the last non-beta release (2011’s 9.0.302) to the last beta release (about 1.5 years ago), depending on their different policies about running betas, even sharing patches in a useful fashion was going to be quite difficult.

So, I spun up a project at Open Kermit to coordinate future development in the open and keep Kermit going.

With modern CI, I run that test suite on Linux (x86_64 and arm64), macOS, FreeBSD, NetBSD, and OpenBSD. It builds binary releases on all those platforms, plus a statically-linked Linux binary built with musl libc.

You can download the latest C-Kermit release, and of course contribute to C-Kermit and its website.

Dedication

Frank da Cruz was directly involved with Kermit for 44 years. I’m not aware of any other Open Source project founder being involved for so long. Richard Stallman started working on GNU Emacs in 1984, 3 years after Frank started working on Kermit, but Richard hasn’t been in that role since around 2008.

Accordingly, C-Kermit 11 bears this dedication:

I dedicate this release of C-Kermit to Frank da Cruz.

Frank was directly involved with Kermit for 44 years, from its initial design in 1981 all the way through 2025. He maintained Kermit as an Open Source project after Columbia University ended its sponsorship. I know of no other Open Source project where the founder remains so personally involved for so long.

When Kermit was begun, transfers between different hardware and operating systems were difficult or impossible. Frank helped build a bridge. Kermit glued systems together, from the International Space Station to pocket calculators, and set a new standard for interoperability. It continues to do so.

Kermit is still one of the quietly-working pillars of computing today, enabling everything from firmware upgrades to radios. And, yes, it still reliably transfers files over serial lines.

As we start to spend a lot of time in the Kermit codebase, we do so standing on the shoulders of a giant. Thanks, Frank, for your decades of work on Kermit.

John Goerzen, July 2026

16 thoughts on “Celebrating 45 Years of Kermit with the First New C-Kermit Release in 15 Years (and working with a decades-old C codebase)

  1. Yes, the guy that resurrected UMN #gopher is at it again. This time, I've made the first new #Kermit release in 15 years! https://changelog.complete.org/archives/44456-celebrating-45-years-of-kermit-with-the-first-new-c-kermit-release-in-15-years-and-working-with-a-decades-old-c-codebase This protocol, originally for serial lines, lives on and I use it as a powerful ssh wrapper daily. I added a modern test suite, fixed a ton of bugs, added IPv6 support.

    And, rather to my surprise, ENJOYED working in a legacy #C codebase.

    1/

  2. @jgoerzen awesome!

    Do you know if there are any plans for the same sort of thing for gkermit?

    1. Not as far as I know. gkermit had several goals, and one was being able to be included in Linux distributions at a time when Columbia’s license on C-Kermit prevented that. Another was having a small footprint. Now that C-Kermit is BSD-licensed and has a footprint that is tiny by modern standards, there’s not as much demand for gkermit anymore. That said, the source is out there if someone wants to do the same!

  3. …the Frog? #kermit

  4. @jgoerzen now that is a name I've not heard in a long, long time…

    I was a maintainer of Kermit for a number of years. C-Kermit on Atari ST, Kermit65 on Apple ][ and 8bit Atari, and *Kermit on MTS mainframe. Haven't touched any of it since the 1990s after I had 9600baud serial line internet access.

  5. All I can say is that last month I rescued an old (presumed dead) HP48 calculator.
    After successfully reviving the electronics, it was time for the software: a simple serial cable and the old trusted c-Kermit to the rescue. Thank you Mr. Goerzen.

    1. I still have my HP48, but my college-age son has commandeered it for his classes, so I don’t get to use it very often. Though, through an emulator, it is my primary Android calculator still. Glad it helped!

  6. In the late 80’s through the middle of the first decade of the century (“the middle of the 2000s” seem wrong…) I was a keeper of trivia of PC UNIX serial ports, as a firmware/driver engineer making high-performance multiport serial boards and multimodem products and later a kernel dude at a UNIX company. I’d comped him some hardware along the way I was still (very intermittently) helping Frank as recently as 2022. He was (is?) committed to the craft, for sure.

    https://github.com/OpenKermit/ckermit/blob/abe250a1db65fd4033adae08901af769d311ddaa/ckcmai.c#L453

    Makes the 25 years on my own open source project, GPSBabel, seem childish.

    1. Wow, small world. Thatnks for that help along the way!

      And thank you for GPSBabel! I have probably been using it for all of those 25 years. Initially with some old Garmin GPS devices I barely remember the name of (GPS III and eMap maybe?), and now still to process and convert logs from flights in my little plane. I have a little script that does: gpsbabel -t -i kml -f “$1” -x simplify,count=2000 -o unicsv -F “$1.csv”

      I, in fact, packaged up gpsbabel for Debian in 2004 and maintained it there until 2008.

      1. I just looked carefully at my mail. We share something else. :-) (Beyond the blessing/curse of relatively unique last names that make mailbox searches unambiguous.)

        And, yes, I see you back to 2005. /waves! :-)

  7. @jgoerzen No one will ever pay tribute to a code-mangling LLM in this way.

  8. @jgoerzen what about archived resources old kermit code. I sometimes still use kermit on MS-DOS/FreeDOS. Should I download and preserve all this code in my private library?

Likes

Reposts

Mentions

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

To respond on your own website, enter the URL of your response which should contain a link to this post's permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post's URL again. (Find out more about Webmentions.)