Older blog entries for dtucker (starting at number 37)

OpenSSH is now in a feature freeze for the 3.7 release. We're down to the testing and shaking out bugs, so if you have a platform you'd like it to work on, please grab a snapshot from a mirror near you and try it (and report any problems you find).

I haven't seen the proposed release notes yet, but the kind of things that have changed (in no particular order) are:

  • Kerberos4 and AFS support has been removed
  • The Kerberos5 support has been replaced with GSSAPI support based on Simon Wilkinson's work
  • The PAM support has been replaced with the implementation from FreeBSD
  • Regression tests should now run on most platforms
  • (Hopefully) has less bugs and works on more platforms

Since I'm a sucker for oddball OSes, and GNU HURD seems odder than most, I was also going to have a look at why PrivSep doesn't work on it. Unfortunately, it appears that since the GNU ftp server was h4x0red, the HURD packages were taken offline and no one can currently install a HURD system. Oh, well, maybe later.

You can verify a host key like so:
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

It's documented in the man page for ssh-keygen.

All of the pending OpenSSH patches for old Linux and Cygwin have been merged, so if you want to try them, the snapshots have them.

I've been looking further into the OpenSSH timing/information leak issues (ie you get noticably faster or slower responses depending on why your connection was denied), which seems to be a can of worms. I started a discussion thread to hopefully thrash out the remaining issues.

Synced a whole stack of pending changes from OpenBSD's ssh to Portable, which included the removal of Kerberos4/AFS support. After the changes, I checked the tinderbox and found and fixed a few minor problems. I also tried to build it on Cygwin which failed, so I posted a patch for that.

Last week I found a really old Redhat CD (3.0.3, which sports kernel 1.2.12 and libc 5.2!) while cleaning up and decided to load it on my test box. This to test a patch fixing build problems on old Linuxes. So, if you're nutty enough to be running something that old, grab yourself a snapshot, apply the patch, and you too can have a modern OpenSSH running on your system! You may have to disable Privilege Separation (or compression), since mmap() seems broken. Anyone running anything older is on their own (but hey, if you make it work, send a patch!).

And I finally investigated a Debian OpenSSH bug report that I said I'd look at (192207) where 3.6.1p2 adds a several-second delay on login. This ended up being related to two other bugs (99168 and 193546). In the current tree that code had changed quite a bit, so it wasn't possible to just backport a fix, so I sent an explanation and patch that should resolve the problems with only minimal changes to 3.6.1p2.

One other thing that occurred to me today: does anyone put copyright notices or licenses on patches? I always consider any patches of mine implicitly have the same license as the code it's patching, but do I need to make it explicit?

The other day I noticed that IBM are now shipping OpenSSH Packages that include my password expiry patch. I knew they were going to do that but it's cool to actually see it. Hopefully the increased userbase won't find any extra bugs :-)

The patch includes other AIX login-related fixes (eg to correctly record logins when a non-password authentication is used) and I've been breaking it up into pieces for merging into the main tree. The current piece is the actual AIX password expiry component which is awaiting review. Following that will be support for platforms using /etc/shadow, then the AIX login recording fixes (which will need an extra monitor call to be added to OpenBSD's sshd).

Replaced my aging full-tower server (a 366MHz K6-3) with a VIA Mini-ITX system. Although it's 933MHz it seems to do less per cycle and has a smaller cache, so it's only roughly 50% quicker. On the other hand, it's quiet, smaller than my VCR, uses about 20W of power, has half a gigabyte of RAM and mirrored 80GB disks and I can stuff it into a cupboard out of the way. Just don't try to boot an i686 kernel on it.

Spent some time going through my openssh work-in-progress trees and merged some of the minor outstanding things (some AIX version compatibility issues, build fixes for other platforms and a few other minor fixes). Managed to close a couple of outstanding bug reports too.

Here's a really good way to annoy an member of an open software project (well, me anyway):
User: Your software doesn't work on platform $FOO.
Us: Fiddle this, change that, try this, add this.
User: Great, that works if I do this and that and compile with this compiler flag and a westerly tailwind.
Us: Excellent. Try this patch, it should work unmodified. Tell us if it works and we'll change it so it works properly in future.
User is never heard from again.

Repeat several months later with another user and the same platform.

People, please, if you're going to report problems to open software projects, it's your responsibility to follow up. It's your end of the bargain. We will do our best to help you solve your problem, and in return you should help us improve the software. If it's not possible, it's fine to say so (for example, if you no longer have access to that system) but just vanishing without following through is highly annoying.

For those not familiar with the project, the core SSH functionality is developed in the OpenBSD tree, while all the cross-platform support is developed in a separate Portable tree. This means that periodically the core changes need to be imported into the Portable tree (an "OpenBSD CVS Sync"). I've been learning to use the tools to do CVS syncs of the main code. In doing so I've gained an appreciation as to why the way I do some things make syncing harder (eg it's preferable if platform-specific changes should go in a Portable-only source file, or failing that in a block of code distinct from the OpenBSD code to make merging changes easier).

I also wrote a couple of new regression tests (one to test reconfiguring sshd via "kill -HUP", which would have caught a problem we had in -portable, and one to test ssh's DynamicForward SOCKS4 and new SOCKS5) support. There wasn't any grand plan for these tests, it just occured to me that they were possible and that they could be made mostly from parts of existing tests, so I did. Both tests are now part OpenBSD and -portable.

Coincidence of the day
I happened to be near near the workplace of a friend of mine today. I hadn't seen him for quite a while so I gave him a call and caught up over a coffee.

He now works for a system vendor who ship an OpenSSH-based ssh package. Partway throught the conversation:
Him: "Hey, you work on OpenSSH, right? I have this customer with this wierd problem..."
Me: "I think I fixed that a couple of months ago."
I guess that made the coffee break work-related for him:-)

Started working on the OpenSSH regression tests again. OpenBSD has a system-wide test suite and OpenSSH Portable imports the ssh tests. They're shell scripts (I think it was Larry Wall who said "it's easier to port a shell than a shell script") and they don't work on many of the platforms that -portable supports.

I have pulled in all the recent changes from OpenBSD so they're in sync at the moment. I also posted a largish patch that makes them work on many other platforms. If these portability changes are accepted back into OpenBSD's tests, then the same tests can be used for both. If not, -portable's tests will have to be a branch, much like the rest of OpenSSH.

Had a few quiet drinks with a friend on Friday night. Woke up Saturday feeling like I'd been hit by a Club. A Canadian Club, actually. Investigation proved the previously-full bottle to be empty. Oww.

Went camping over (long) the weekend with a couple of friends. Great to spend time with them but up in the mountains it was bl**dy freezing....

28 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!