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/

Steve Freeman boosted

John Goerzen » 🌐 2026-08-03
@jgoerzen@changelog.complete.org

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 #ifdef 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

#ifdef #kermit #Software

Two things you can see here... It's pretty hot! That's why I stayed home and implemented a missing feature into snac. That's what you can also see - it finally sends push notifications to devices! In this case, we can see notifications coming from #MastoBlaster App for iPhone.

What we can also see, it's still a bit faulty and not the expected content, but a first success here at least ;) I'll make some further adjustments when there's time and get in touch with @grunfink@comam.es to check if we can get this upstream. Thanks to @stefano@bsd.cafe for testing with me :)

#fediverse #mastodon #fedi #activitypub #snac2 #c #programming #clang #MastoBlaster

Alt...

snac2 sending push notifications to a user via MastoBlaster App on iPhone

"The #C #Programming Language"
K&R C 1ed (1978)

I've owned this little treasure for over 40 years. I've reread it countless times through the years, just for inspiration. It is still my all-time favourite #technical #book.

Alt...

K&R C 1ed (1978)

I like this documentation.

https://www.youtube.com/watch?v=lI7tMxzSJ7w

#programming #c++ #cpp #unix

#linux #gcc #clang #c #cpp #poll 1) do you have a program called "a.out" in your home folder, and if so 2) do you remember what it was

How Factorio Syncs A Million Objects over the network https://lobste.rs/s/2r03i7 #video #c++ #games
https://www.youtube.com/watch?v=0FHSZ1hani0

code.fail: C Version with x86+ARM shellcode

Here is an exploit written in C for the the copy.fail (https://copy.fail/, CVE-2026-31431) vulnerability. The embedded shellcode works on other CPUs than X86, with ARM as a primary target.

Code: https://github.com/huberteff/copy-fail-CVE-2026-31431/
Technical writeup: https://www.feyrer.de/redir/copy.fail-C-version-Writeup.html

#copyfail #exploit #c #arm #x86 #cybersecurity

C version of https://copy.fail? Sure:

% head -1 cfc.c
// C version of https://copy.fail by Hubert 'hubertf' Feyrer
% make cfc
gcc cfc.c -o cfc -I/usr/include/node -L/home/feyrer/pkg10/lib -lz
% ./cfc && su
Starting XFRM IPSec tunnel simulation...
Decompressed size: 160 bytes
First few bytes: 7f 45 4c 46...
Processed 0/160 bytes
Done processing 160 bytes
Executing su...
# id
uid=0(root) gid=42(feyrer) groups=42(feyrer),27(sudo)
#

#copyfail #cybersecurity #c

I just saw some C++ posted, and it made me think:

Write in C!

https://www.youtube.com/watch?v=H4YRPdRXKFs

#c #WriteInC