Older blog entries for dtucker (starting at number 40)

12 Oct 2003 (updated 12 Oct 2003 at 11:19 UTC) »

Sifted through 350 messages waiting in my Inbox. There's a few OpenSSH-related things still to be dealt with, but most could be filed. Started looking at the outstanding PAM-related issues.

After the Swen.W32 spam-a-thon (which peaked at 1 every 30 seconds or so, see previous diary entry) I've made my spam filtering more savage and for the first time I'm sending spam straight to the bit-bucket (anything scoring 15+ on the spam-o-meter). It seems like admitting defeat. I used to report every spam I got, then when I started using spamassasin, just the ones that got past it. I rarely got a response. Now I just use spamassassin -r to submit any getting past the filters to DCC. If it wasn't for filtering, my email would be totally unusable. Even that only reduces the human cost and hides the bandwidth and storage costs. The spam didn't start until I started posting to public mailing lists and has got steadily worse. I guess it's the cost of working on a public project.

18 Sep 2003 (updated 19 Sep 2003 at 04:17 UTC) »

Sigh. Another day, another freakin' Windows worm. I've already got several megabytes of the damn thing.

Daz's SpamAssassin tip of the day:

echo "score MICROSOFT_EXECUTABLE 10.0" >>/etc/mail/spamassassin/local.cf
Why this isn't the default I don't know.

Now all I need to do is work out if I can filter it before I download them.

Update: 80 copies in 5 hours (about 12MB worth of crap). I think I'm hit worse than normal because I've been more active the SSH mailing lists in the last couple of days, so I'm more likely to be selected as a target.

I just set a size limit in fetchmail (limit 130000 in .fetchmailrc) so at least I don't have to download the suckers. I will have to clean out the mailbox periodically, though.

18 Sep 2003 (updated 18 Sep 2003 at 22:36 UTC) »

I've seen release circuses before, I even had a ring-side seat for the last one, but this is my first from inside the ring.

In case you've been living under a rock, you've probably heard that OpenSSH has some buffer management issues. The jury is still out on whether or not it's explotable, but regardless, there was a massive scramble for release. If you haven't already, you should apply the patch or upgrade.

Naturally, since it was a rush release, there was breakage. Despite requests to test for the impending release, it looks like no-one with (IRIX, Tru64, BSDi, MacOS X) ever tested it and those are all broken. There are also other issues with certain configurations (including, sadly, one I'm responsible for). You can check the score over at bugzilla. Meanwhile, the list server is melting down (currently ~12 hours behind, but still delivering!)

By coincidence, my next job was postponed by the customer (again!), so I've been on deck juggling as many of the bug reports as I can. If you get only a terse response from me (or none), that's why.

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.

BenFrantzDale:
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.

31 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!