dtucker is currently certified at Master level.

Name: Darren Tucker
Member since: 2002-07-06 02:05:33
Last Login: 2014-02-02 11:30:16

FOAF RDF Share This

Homepage: http://www.dtucker.net/


I am an OpenSSH developer. In the beginning, I wrote the AIX native package utility, and over time my work expanded in several directions. I now work on many aspects of OpenSSH, both Portable and OpenBSD's.

I've contributed patches to several projects, and I try to provide comprehensible bug, reports where possible.

I also run a tinderbox which monitors the status of the current OpenSSH tree on various platforms.


Recent blog entries by dtucker

Syndication: RSS 2.0

Went to AUUG2005 last week. It was quite interesting for a couple of reasons: I got to meet some of the other OpenBSD and OpenSSH folk (none of whom I had met before), I got to meet some folk from other projects and saw some interesting presentations.

On the OpenBSD side, djm presented a paper on Secure Portability and Reyk Floeter presented a paper on OpenBSD's wireless support and hostapd. Among the other presentations, Brian Cantrill's on Dtrace in Solaris, Steve Landers' on crypto APIs in TCL and Peter Gutmann's on Sustainable Open Source Development were particularly interesting.

Over a few drinks after djm's presentation, Peter was talking about some kind of knowledge base containing what had been learned during the porting process, with us, the MySQL folks and possibly others. It sounded like a good idea at the time, and, somewhat surprisingly, still did the following day.

Stuart Smith from MySQL has now set up the PortaWiki to start the process off. I've just spent an hour or so writing articles for it from where the existing content fired random neurons.

Ultimately, I'd like to see the same content indexed by both function and platform. This would cover the 2 common cases in my experience: "I'm porting to platform FooBar, what are the gotchas?" and "I'm thinking of using the fobar() function, where is that going to bite me?" Hopefully this will turn into a valuable resource.

Why can't a non-root user do this?
$ dd if=/dev/zero of=img bs=1024k count=1
$ mke2fs -F img
$ mkdir mnt
$ mount -t ext2 -o loop img mnt

Remember, the file is completely under the control of the user. If that was allowed, the user could create a root-owned binary inside the image (eg a copy of /bin/sh) and flip the setuid bit on it, mount the filesystem and run the now-setuid binary. Or create a device node for /dev/kmem and go rifling through kernel memory. Or create a device node for the root filesystem then edit /etc/passwd via the raw device. And probably other things I've overlooked.

In unrelated news, one of the reported bugs OpenSSH bugs turned out to be an OpenSSL bug. It took the OpenSSL folks about 15 minutes to accept the bug and apply my patch. I love it when it works like that.

ingvar: NetBSD's libedit/editline library provides similar functionality to GNU readline, and it includes a readline compatibility header so it's at least partitially API compatible.

There's a couple of multi-platform ports, one by Jess Thrysoee which seems to be actively maintained, and a sourceforge project which doesn't seem to have been touched for a while. There's also a couple of platforms (Debian, Mandrake) that have versions that seem to be based directly on NetBSD's CVS tree.

(The reason I know this, BTW, is that in the current development versions, OpenSSH's sftp now uses libedit for command-line editting. It's always enabled in OpenBSD -current, and it's optionally enabled in Portable by ./configure --with-libedit. djm did the coding, I just did the configure bits.)

12 Dec 2004 (updated 13 Dec 2004 at 08:45 UTC) »

First, in the interests of disclosure: I'm one of the OpenSSH and OpenBSD developers, and the person responsible for the Portable branch of OpenNTPD. That said, the following is purely my own opinion.

I've decided to address some of the issues raised by Brad Knowles in an article entitled OpenNTPd Considered Harmful. While I think some of his points are valid (and some of those have been addressed since it was written), I disagree with others and some are quite misleading.

stratum and refid (ntptrace)
The comments about stratum and refid (the comment about ntptrace): these are valid points. They have been have been fixed for a while in the development tree and now in the openntpd 3.6.1 release.

I don't think the criticism about portability is warranted. At the time that article was written Portable OpenNTPD already supported Solaris (it was the 2nd target I did after Linux) and HP-UX support has since been added. I don't think it's valid to criticise a project that's only existed for a couple of months for "only" running on Linuxes, *BSD's, Mac OS X, and Solaris (which covers the 3 main *nix families in use today, Linux, BSD, System V). I suspect it's probably portable to any platform with a POSIX interface and an adjtime() syscall (or something that behaves like it) [update: and a good entropy source (such as /dev/random or a self-seeding OpenSSL)]; it already runs on every system that I have access that meets those criteria with the exception of one (and that one is for non-technical reasons).

Brad also says that the OpenNTPD developers "seem to be violently opposed to using certain methods which are known to be more portable, in favour of using techniques which are specific to OpenBSD". I'm not aware of what he's referring to here. There are several instances of changes in OpenBSD for the purposes of improving portability (eg 1, 2, 3) and if there are ways of doing things in -Portable to improve portability then I would be interested to hear them.

Finally, he describes the automated test procedures they use on the "flock of test/development machines we have at our disposal". Since the article was written I have added build and basic functionality tests for OpenNTPD to tinderbox automated tester that we also use for OpenSSH (the machines which appear will vary depending on which machines I have running at the time). BTW the key phrase here is at our disposal: we can't test on systems we don't have access to.

Split development
About the split OpenBSD/Portable development model, Brad says that it "pretty much guarantees that the two code bases will quickly diverge quite dramatically". This is not necessarily so: as a counterexample, OpenSSH has operated with this model for five years quite successfully. It requires discipline, but it can work. It is not a coincidence that OpenNTPD's portability layer looks like OpenSSH's.

In the case of OpenNTPD, the split between OpenBSD and Portable is quite clean and the differences in the common code are small, a total of approximately ~70 lines for 3.6.1p1 including man page diffs. (The diff is in the Portable tarball).

Clock disciplining
The comment about clock disciplining (compensation for systematic skew or drift) is a fair point, within limits. Right now OpenBSD doesn't permit changing of tickadj at the default securelevel so another mechanism is needed in the kernel. When this happens, ntpd will probably learn how to do it. (Note: this does not necessarily prevent it from being done on other platforms, for example see my experimental patch that adds crude skew compensation via adjtimex to Linux, which is implemented with zero changes to the common code.)

I would like to point out, though, that the charge of "jumping the clock forward or backward" is very misleading: at the time the article was written, OpenNTPD would never cause the clock to jump either forward or backward: the offsets are filtered (although the filters could be improved) and the adjustments were always done via adjtime (a "slew") which means the time is always monotonically increasing. Even now, the only time it will use settimeofday (a "step") for the first adjustment, and only if this behaviour is enabled with the -s option. In contrast, the reference implementation in its default configuration will step the clock any time the offset exceeds 128ms (see the ntpd man page, specifically the "-x" option).

Alternative server modes
Brad criticizes OpenNTPD for not imlementing broadcast, multicast and anycast modes because "the NTP protocol can put a heavy load on the server, and trying to handle thousands of clients, each in direct one-to-one communications, just isn't feasible".

Dr David Mills describes a Stratum-1 server running on a SPARC IPC (a 25MHz machine) serving 734 clients while using 1.54% of the CPU and concludes "that substantial numbers of clients with no significant degradation on other network services". Arithmetic suggests that even this long-obsolete machine could support thousands of clients.

While OpenNTPD doesn't support these modes now, it may in future, however it's not clear how much of a gain these would be in many environments. Broadcast mode is limited to the local network, thus it would only be necessary in environments where there are more clients in a single subnet or broadcast domain than can be handled by a single server. Multicast mode requires the network to support multicast routing (eg IGMP, DVMRP, MOSPF), although in an environment that supports it, it could result in a reduction of WAN traffic. Anycast mode is described in RFC 2030 as "provisional", and doesn't help with load, it only helps in locating a server, after which it operates in unicast mode.

Authentication and crypto
Regarding the comment about authentication and crypto: it depends on what your threat profile is. Brad correctly points out that it's not a zero-sum game. It is, however, a tradeoff: you're trading a reduction in risk that someone will be able to perform an active attack against your clock for an increased risk of a security issue in the additional code required to implement it. There's no way to prove the relative weights in this tradeoff, it's a matter of opinion.

As Brad points out, OpenNTPD's "cookies" always provides some protection against blind spoofing of responses. They're by no means perfect, but they're a simple measure that provides cheap insurance and requires no configuration or additional support in the server.

The symmetric-key authentication in NTP v3 seems to have limited deployment (probably due to key distribution issues and administrative overhead, and it appears that most public servers don't offer it) and is listed as optional in RFC 1305.

I can't comment much on the public-key modes in NTP v4 as at the time of writing the NTP v4 spec is not available, although from the description of the Autokey protocol it appears that it is based on X.509v3 certificates. I will only point out that OpenSSL's ASN.1 parser and X.509v3 code runs to around 15,000 lines (probably due to the general wackiness of X.509 [1]), and this is a significant amount of additional code to be running in a daemon that accepts input from the network (via a transport that, as Brad points out, can be trivially spoofed).

Lack of Features
(also known as "simplicity"). Guilty as charged.

If you need a feature the OpenNTPD doesn't have (and, indeed there are many), or need greater accuracy than it can provide, or if you just prefer it, then by all means use ntp.org's software (or any other software for that matter). If you want a small daemon that will do a decent job of keeping your clock in sync while running mostly unprivileged, then OpenNTPD may suit. If it does, great. If not, and you decide to use something else, that's fine too. You have another option, which is why I started the Portable branch in the first place.

[1] For an overview of said wackiness, see Peter Gutmann's PKI Tutorial, subtitled "Everything you Never Wanted to Know about PKI but were Forced to Find Out", and for a comprehensive treatment see his X.509 Style Guide).

OpenSSH celebrated its fifth birthday this week.

51 older entries...


dtucker certified others as follows:

  • dtucker certified alan as Master
  • dtucker certified rms as Master
  • dtucker certified miguel as Master
  • dtucker certified janfrode as Apprentice
  • dtucker certified markus as Master
  • dtucker certified djm as Master
  • dtucker certified jwz as Master
  • dtucker certified ncm as Master
  • dtucker certified ib as Journeyer
  • dtucker certified lerdsuwa as Journeyer
  • dtucker certified robocoder as Apprentice
  • dtucker certified davem as Master
  • dtucker certified davej as Master
  • dtucker certified akpm as Master
  • dtucker certified mulix as Master
  • dtucker certified lkcl as Master
  • dtucker certified jallison as Master
  • dtucker certified gorny as Apprentice
  • dtucker certified anholt as Master
  • dtucker certified mharris as Master
  • dtucker certified laredo as Journeyer
  • dtucker certified elliot as Apprentice
  • dtucker certified mbp as Master
  • dtucker certified rmk as Master
  • dtucker certified riel as Master
  • dtucker certified SyOpReigm as Journeyer
  • dtucker certified garym as Journeyer
  • dtucker certified chalst as Journeyer
  • dtucker certified ploppy as Journeyer
  • dtucker certified daniels as Journeyer
  • dtucker certified vivanovic as Apprentice
  • dtucker certified IlyaM as Apprentice
  • dtucker certified jaldhar as Journeyer
  • dtucker certified hpa as Master
  • dtucker certified Fyodor as Master
  • dtucker certified Akira as Journeyer
  • dtucker certified jolan as Journeyer
  • dtucker certified fxn as Journeyer
  • dtucker certified ebf as Journeyer
  • dtucker certified mct as Journeyer
  • dtucker certified jgarzik as Master
  • dtucker certified robertc as Master
  • dtucker certified cjwatson as Master
  • dtucker certified dhartmei as Master
  • dtucker certified gert as Journeyer
  • dtucker certified senthilkumar as Apprentice
  • dtucker certified tagishandy as Journeyer

Others have certified dtucker as follows:

  • janfrode certified dtucker as Journeyer
  • ib certified dtucker as Apprentice
  • djm certified dtucker as Master
  • ncm certified dtucker as Apprentice
  • lerdsuwa certified dtucker as Journeyer
  • gorny certified dtucker as Journeyer
  • SyOpReigm certified dtucker as Journeyer
  • ploppy certified dtucker as Journeyer
  • davej certified dtucker as Journeyer
  • elliot certified dtucker as Apprentice
  • fxn certified dtucker as Journeyer
  • linn certified dtucker as Journeyer
  • jolan certified dtucker as Journeyer
  • xsa certified dtucker as Journeyer
  • grey certified dtucker as Journeyer
  • ebf certified dtucker as Journeyer
  • pasky certified dtucker as Journeyer
  • santana certified dtucker as Journeyer
  • senthilkumar certified dtucker as Master
  • Logu certified dtucker as Master
  • jblnyc certified dtucker as Journeyer
  • dma certified dtucker as Master
  • Miod certified dtucker as Master
  • bod certified dtucker as Master

[ Certification disabled because you're not logged in. ]

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!

Share this page