Older blog entries for dtucker (starting at number 49)

OpenBSD -current now has a small, simple NTP daemon as an alternative for the large, featureful reference implementation. It's small and should be secure (it's privilege separated) and should serve the needs of most people (who don't need the power or features of the reference implementation.)

I've taken this, added autoconf and a portability layer much like (indeed, based heavily on) OpenSSH and produced a portable version. Currently it works on Linux and FreeBSD in addition to OpenBSD. Depending on how well it works out, support for other platforms might be added.

While it's small, it's fully functional for basic sync-to or sync-from requirements, but it doesn't (yet) have the capability to act as a stratum-1 time source. On the other hand, it's an order of magnitude smaller than the reference implementation :-)

$ du -ks /usr/sbin/ntpd /usr/local/sbin/ntpd
328     /usr/sbin/ntpd
36      /usr/local/sbin/ntpd

(both compiled normally, dynamically linked and stripped).

Correction: The latter is compiled without optimization, with -O2 the size is 28KB. I also forgot to mention the funny part: the "configure" script is bigger than rest of the source code combined.

OpenSSH 3.8.1p1 will be released soon (it's a bugfix release), so I sent a call-for-testing.

We run regular tests of the OpenSSH tree (the results go to the tinderbox) and I've been looking at improving the test coverage by building with non-gcc compilers on my Linux box. So far I have found:

• TenDRA, but the last time I tried it it would not build on my box.
• tcc, a small Linux/x86-only compiler.
• icc, which I just found has a non-commercial non-expiring license option.

I played with tcc which seems interesting (and fast), but ran into problems with its library-search behaviour. It would search -L paths last, and it would always use a dynamic library, even if a static library was before it in the library path.

Its code turned out to be quite easy to work with, so I modified it to handle -L/-l more like gcc does and submitted the patch back to the author. I also found what is probably a portability bug in OpenSSH. Unfortunately, some of the OpenSSH binaries produced by tcc segfault for reasons I've been unable to determine, so it's currently not suitable for regular build-and-test use.

Sorted some of the pending OpenSSH bugs into fix for 3.8.1p1 and aim for the next major release.

For the past couple of releases, we've opened a "Release Engineering" bug to tie all of the pending fixes shortly before the release, to make sure stuff didn't get missed. I found myself sorting bugs into "fix now" and "fix later", so I decided to start tracking the "fix later" ones too. There's no guarantee that the listed ones will be done, but it should give folks a rough idea what the plan is.

clarkbw, regarding your self-assessment proposal: I have a book (Maverick! by Ricardo Semler) that describes a much higher stakes version of what you're proposing: at the Brazillian company Semco, most of their senior staff set their own salaries!

Apart from modesty and peer pressure, they have a very real incentive to keep it realistic: the easiest way to solve a budget problem is to get rid of someone drawing an excessive salary! They found that most people set realistic salaries, and of those that didn't all but one set a salary lower than expected.

Anyway, the book is a fascinating read even if you're not into management theories. (I'm not: I picked it up on a whim in a bookshop one day, then realised I had been standing there reading it for over 20 minutes, so I bought it). The book is about 10 years old, it would also be interesting to know what has changed since then.

OpenSSH 3.8 is out. Coming soon to a mirror near you...

There is going to be a new OpenSSH release soon. If you want the release to work on your system, you ought to try out a snapshot.

Particularly, you should try it if you're interested in PAM fixes or Kerberos/GSSAPI support. If you have access to an unusual system or configuration then tests on those are particularly helpful since we can't test all of them.

You can see the bugs that ought to be fixed before 3.8

Hmm, this asking-for-testing thing usually gets only limited responses, since most people prefer to complain after the event. Maybe I should try a little reverse psychology...

There will be a new OpenSSH release soon. Under no circumstances should you try a snapshot. You especially should not test it if you're interested in PAM fixes or Kerberos/GSSAPI support. This goes double if you have an unusual system or configuration, because since we're psychic we always know what's going to break on system's we've never seen or heard of, and magically know what to do to avoid problems.

Yeah, that ought to do it :-)

More OpenSSH hacking. I'm trying to figure out why the new(ish) PAM chauthtok via keyboard-interactive code displays the PAM messages properly on some platforms (Redhat, AIX) but doesn't on others (Solaris, HP-UX). I added some instrumentation to the PAM code to help debug it and spent some time poking sshd with a debugger, but without definitive results. It seems to be related to to message "style" set by PAM when responding to the request, but needs more investigation.

I also noticed a problem whereby the if the PAM authentication thread dies without completing the authentication (either success or failure), sshd will block indefinitely for that session. I have a fix for that, which will go in once a few style nits are sorted out.

Spent a little time looking at dropbear, another SSH2 server implementation. While fiddling with it I got it running on HP-UX, fixed what I suspect was a bug and sent the patch for both back to the author.

Closed a bunch of OpenSSH bugs that had either already been fixed, or the reporters had not followed up with requested information, and updated a few more.

My family is visiting for Christmas, but it still feels like there should be a week or two until then...

Saw Powderfinger live on Saturday. Awesome.

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.