[25] in The Cryptographic File System users list
CFS code to be reorganized (and downsized)
daemon@ATHENA.MIT.EDU (Matt Blaze)
Mon Dec 22 17:04:27 1997
From owner-cfs-users@research.att.com Mon Dec 22 17:04:23 1997
Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by bloom-picayune.MIT.EDU (8.7.6/2.3JIK) with SMTP id RAA03931 for <cfs-mtg@bloom-picayune.mit.edu>; Mon, 22 Dec 1997 17:04:20 -0500
Received: from research.att.com ([135.207.30.100]) by rumor; Mon Dec 22 17:01:17 EST 1997
Received: from amontillado.research.att.com ([135.207.24.32]) by research-clone; Mon Dec 22 17:02:32 EST 1997
Received: from nsa.research.att.com (majordomo@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id RAA11131;
Mon, 22 Dec 1997 17:02:25 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id RAA24624 for cfs-users-list; Mon, 22 Dec 1997 17:02:32 -0500 (EST)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id RAA24619 for <cfs-users@nsa.research.att.com>; Mon, 22 Dec 1997 17:02:30 -0500 (EST)
Received: from nsa.research.att.com (root@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id RAA11082
for <cfs-users@research.att.com>; Mon, 22 Dec 1997 17:02:13 -0500 (EST)
Received: from nsa.research.att.com (mab@localhost.research.att.com [127.0.0.1]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id RAA24611 for <cfs-users@research.att.com>; Mon, 22 Dec 1997 17:02:27 -0500 (EST)
Message-Id: <199712222202.RAA24611@nsa.research.att.com>
To: cfs-users@research.att.com
Subject: CFS code to be reorganized (and downsized)
Date: Mon, 22 Dec 1997 17:02:27 -0500
From: Matt Blaze <mab@research.att.com>
Sender: owner-cfs-users@research.att.com
Precedence: bulk
I've decided to significantly reorganize the CFS code for the next
release after 1.4.0 is finalized. The current code base has suffered
from the bloat of five years worth of porting and patching, and
has long ago gotten somewhat out of my control.
I've spent the last month accumulating, "stone soup" style, processors
that run Solaris 2.6 and Linux 2.0 in addition to my usual BSDI
3.1, SunOS4.1.3 and (somewhere) Win32 boxes. In addition to helping
CFS development, this will also support my winter heating needs...
The most significant change to the CFS code will be that I will
attempt to support ONLY those platforms that I actually have under
my direct control and in my own home (except for Win32, of course).
I will, of course, continue to accept patches for other machines,
but my primary goal will to make sure that CFS compiles, installs,
and runs perfectly cleanly on the "core" platforms. In addition,
now that there are high-quality free ANSI C compilers available
(e.g. gcc) for all these machines, I intend to assume ANSI C with
prototypes at all the function interfaces. Right now, the code
assumes an unholy mix that appears to result (harmless, but still
worrysome) warnings on most platforms.
As it's been, I've been blindly trying avoid breaking platforms
that I don't use myself, which has resulted in all sorts of ugly,
questionable kludges in the code. This must stop. (I discovered
today that there's still support for MACH386 in parts of the code!).
Removing support for other platforms will mean some short-term pain
for some users but will result in much better CFS code in the long
run. In particular, FreeBSD and OpenBSD are ALMOST, but not quite,
the same as BSDI - I'll attempt to avoid stepping on any differences,
but will depend on user-contributed patches to keep me honest.
Irix is a bit more complicated, I think, but my Solaris 2.6 support
should make that less painful that it would be otherwise.
Have I left anyone out? If you're using anything other than BSDI,
FreeBSD, or OpenBSD on an x86, SunOS or Solaris 2.x on a Sparc, or
Irix on an SGI box, please let me know so I can at least feel guilty
about abandoning you.
Also, I'm going to remove ESM from the CFS distribution and make
it a standalone package. There are many fewer ESM users than CFS
users, and now that SSH and, soon, IPSEC, are more widely deployed,
there is little reason for most people to run it these days. The
only reason to run ESM is if you need end-to-end session encryption
over a non-IP link such as through an application-layer firewall
or through, say, a tip connection. Everyone else should probably
get and install IPSEC (where available) or SSH. I've stopped using
ESM myself, now that our firewall supports SSH.
Happy holidays.
-matt
