December 2003 - cypherpunks-legacy

RE: Get ready to start breaking rocks for Herr Klinton
by John Douceur 17 Dec '03

17 Dec '03

>From: Sandy Sandfort <sandfort(a)crl.com> .... >With his arms control policy background and current familiarity >with crypto as non-exportable munition, Phil Zimmermann is a >shoo-in for a seat on the president's Arms Proliferaton Board. >Hell, he ought to be the Chairperson! This may have been intended tongue-in-cheek, but I think this is an excellent idea. Think Phil would be interested in the position? How could we get this going? JD

1 0

Re: "Subway" remailers
by xpat＠vm1.spcs.umn.edu 17 Dec '03

17 Dec '03

maher(a)kauai.UCSD.EDU (Kevin E. Maher) writes: > I think what you've described is essentially a "secondary" >remailer, one which only communicates with other remailers in messages >of a fixed size. I'm pretty sure mixmaster can do this, and additionaly >can split a message into chunks and send them on their way via differen >paths. > > If I've misinterpreted what you were describing, please correctme. Hmmm... think of an egg carton, filled with anywhere between zero and twelve eggs. Each egg has its own itinerary as to how many stops it wants to make at other remailers, and whether it wants to change cartons. The eggs would be entire messages, and could "get off" at any particular stop, or at a random stop (based on # of rides(hops?)). The entire carton would be encrypted from one stop to the next. I would anticipate that the single-message architecture of the cpunk remailer would be retained, and that "riding the subway" would be an optional feature. Of course with "passenger" exchange and waiting you essentially get the mixmaster effect, except you are blind to the actual pathway. (remember the MX-missle system, which planned on moving ICBMs from launch site to launch site in an underground matrix of tunnels?) The only thing you would see from the outside is regular pulses of large cargo-carrying (or not) message containers. It might be a partial cover-traffic solution as well, though you still have to worry about entering and exiting the subway system, it's just that it somewhat breaks the identifiable direct traffic-trace links. An even more advanced feature could allow an individual to submit an entire container (loaded with different messages) to the subway system (although this may give an attacker clues about any weakness in randomizing pathways internal to the system, for users utilizing default features). Imagine only submitting one or two messages a day that delivered twenty-five. That might really furrow a traffic analyst's brow. More or less that extends the subway paradigm outside the ring of the system, at least partially, I would guess. I am unsure if there is an existing term for this, but how about "composite mail" containing "aggregate messages"? ------------------------------------------------------------------ P M Dierking |

1 0

Re: Mixmaster and remailers
by Hal 17 Dec '03

17 Dec '03

From: lcottrell(a)popmail.ucsd.edu (Lance Cottrell) > Even if you are using a perfect network of remailers, you can still be > tracked. Only so many messages pass through the network of remailers in any > given day. If Alice sending a message usualy correlates with Bob receiving > a message, it is likely that she is sending messages to him. This was > discussed in some detail in several messages by Hal and Louis Cypher. Actually I don't think I considered this aspect of the problem. Probably you are thinking of Wei Dai's posts along with LC's. Hal

1 0

RE: Get ready to start breaking rocks for Herr Klinton
by John Young 17 Dec '03

17 Dec '03

On Fri, 27 Jan 95 John Douceur <johndo(a)microsoft.com> said: >This may have been intended tongue-in-cheek, but I think this is an >excellent idea. Think Phil would be interested in the position? How >could we get this going? One well-travelled path to success is through the Foreign Policy Association, and being published in the journal "Foreign Affairs". Many of the wonks climbed this greasy pole -- Kissinger et al. Thus, an article on cryptography, PGP and its beneficial use for -- or threat to -- foreign policy and arms control might be sent to the publisher: James Hoge, Editor Foreign Affairs 58 East 68th Street New York, NY 10021 (212) 734-0400 The Foreign Policy Association runs seminars, junkets, fellowships, retreats, advances, and cartels for aspiring and decrepit world leaders and public opinion spew-gushers. So perhaps there might be receptivity to a seminar on PGP and public crypto for the high-domed dim-bulbs. Foreign Policy Association 729 7th Avenue, 8th Floor New York, NY 10019 (212) 764-4050 Then, there's the Carnegie stable of world meddlers which sponsors fledging and sinewy American eagles and vultures: Carnegie Council on Ethics and International Affairs, 170 East 64th St, NY, NY 10021. Carnegie Leadership Program, 170 East 64th St, NY, NY 10021 Carnegie Commission on Science, Technology & Government, 437 Madison, NY, NY 10021. Carnegie Foundation, 437 Madison Avenue, NY, NY 10021 (the main honey pot). Carnegie Foundation for World Something in DC. These and a cackling aviary in VA black-farms are the roosts of the big arms poachers and clip-wingers. Golly, must dear tender Phil hang with these peckerwoods?

1 0

Traffic monitoring (Was: Reordering, not Latency)
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- eric(a)remailer.net (Eric Hughes) wrote: > If I were doing global Internet monitoring, I wouldn't be doing it > in-band. Too much cooperation by the vendors required; too much > discovery. Rather, I'd gain access to the trunks directly and do my > own demodulation and decoding. How would you get access to the trunks? Aren't they mostly optic fibers now? Also, since Internet traffic is growing at a geometric rate, the probability of anyone or any organization having the capacity to monitor and process ALL of Internet traffic should be very small and decreasing. It would be much easier to install sniffers on selected local networks (e.g., those containing remailers or other entities you're interested in). Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLyirWjl0sXKgdnV5AQG12QP+LXVa/INx3JmwBqmSrZo8kNiteYIG9AwV 9hG+3qUt6/yvkz0v137lPVOGK+J78MkCDVYnPHeBcdYwmZ7Z8mpfaQGaPQnMnj9x Q9z9hbK9JVBYaN7Hpv0OtIobKn2OlEsJjdZxr8mcuqVN/OS1kHarmhtM2pyfxJ/l uY5/UGIlprA= =jIHR -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai(a)eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> Big Bang --> atoms --> complex macromolecules --> biological evolution --> central nervous systems --> symbolic communication --> consciousness --> computers --> internetworking --> close-coupled automation --> high-bandwidth brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ?

2 1

CIAC Bulletin F-09: Unix /bin/mail Vulnerability (fwd)
by Mike Acklin 17 Dec '03

17 Dec '03

Just got this in the mail and thought I would share it with all of you... ---------- Forwarded message ---------- Date: Fri, 27 Jan 1995 11:16:55 -0800 From: Steve Weeber <weeber(a)eek.llnl.gov> To: hroller(a)metronet.com Subject: CIAC Bulletin F-09: Unix /bin/mail Vulnerability _____________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ _____________________________________________________ INFORMATION BULLETIN Unix /bin/mail Vulnerabilities January 27, 1995 1030 PST Number F-09 _____________________________________________________________________________ PROBLEM: The Unix /bin/mail utility contains security vulnerabilities. PLATFORMS: DEC OSF/1 1.2, 1.3, and 2.0 DEC Ultrix 4.3, 4.3A, and 4.4 SCO Unix System V/386 Release 3.2 OS Version 4.2 SCO Open Desktop Lite Release 3.0 SCO Open Desktop Release 3.0 SCO Open Server Enterprise System Release 3.0 SCO Open Server Network System Release 3.0 Solbourne OS4.1x SunOS 4.x DAMAGE: Local users may gain privileged (root) access. SOLUTION: Apply appropriate vendor patch as described below. _____________________________________________________________________________ VULNERABILITY The vulnerabilities in the /bin/mail program have been openly ASSESSMENT: discussed in several Internet forums, and automated scripts exploiting the vulnerabilities have been widely distributed. These tools have been used in many recent attacks. CIAC recommends sites install these patches as soon as possible. _____________________________________________________________________________ Critical Information about Unix /bin/mail Vulnerabilities The /bin/mail utility on several Unix versions based on BSD 4.3 Unix contain a security vulnerability. The vulnerability is the result of race conditions that exist during the delivery of messages to local users. These race conditions will allow intruders to create or modify files on the system, resulting in privileged access to the system. Below is a summary of systems known to be either vulnerable or not vulnerable. If your vendor's name is not listed, please contact the vendor or CIAC for more information. Vendor or Source Status ---------------- ------------ Apple Computer, Inc. Not vulnerable Berkeley SW Design, Inc. (BSDI) Not vulnerable Cray Research, Inc. Not vulnerable Data General Corp. Not vulnerable Digital Equipment Corp. Vulnerable FreeBSD Not vulnerable Harris Not vulnerable IBM Not vulnerable NetBSD Not vulnerable NeXT, Inc. Not vulnerable Pyramid Not vulnerable The Santa Cruz Operation (SCO) Vulnerable Solbourne (Grumman) Vulnerable Sun Microsystems, Inc. SunOS 4.x vulnerable Solaris 2.x not vulnerable Patch Information ----------------- DEC The /bin/mail patch is a part of a comprehensive Security Enhanced Kit that addresses other security problems as well. This kit was released on May 17, 1994 and was described in DEC Security Advisory #0505 and CIAC Notes 94-03. OSF/1 users should upgrade to a minimum of version 2.0 and install Security Enhanced Kit CSCPAT_4061 v1.0. Ultrix users should upgrade to at least version 4.4 and install Security Enhanced Kit CSCPAT_4060 v1.0. Both kits are available from your Digital support channel or electronically by request via DSNlink. SCO Vulnerabilities in SCO's /bin/mail utility are removed by applying SCO's Support Level Supplement (SLS) uod392a. It is available via anonymous FTP from ftp.sco.com in the /SLS directory: Description Filename MD5 Checksum ------------ ------------- -------------------------------- Disk image uod392a.Z 2c26669d89f61174f751774115f367a5 Cover letter uod392a.ltr.Z 52db39424d5d23576e065af2b80aee49 Solbourne Grumman System Support Corporation now performs all Solbourne software and hardware support. Please contact them for further information: E-mail: support(a)nts.gssc.com Phone: 1-800-447-2861 FTP: ftp.nts.gssc.com Sun Sun has made patches available to remove vulnerabilities in /bin/mail. These patches address all vulnerabilities CIAC has seen exploited to date, and CIAC recommends they be installed. However, the patches will be updated again in the near future to remove additional vulnerabilities that have recently come to light. CIAC will announce the availability of the new patches when they are released. The patches may be obtained from your local Sun Answer Center or through anonymous FTP from sunsolve1.sun.com in the /pub/patches directory: SunOS Filename MD5 Checksum ------- --------------- -------------------------------- 4.1.x 100224-13.tar.Z 90a507017a1a40c4622b3f1f00ce5d2d 4.1.3U1 101436-08.tar.Z 0e64560edc61eb4b3da81a932e8b11e1 Alternative Solution -------------------- For those sites unable to obtain a vendor patch for a vulnerable version of /bin/mail, a replacement package called mail.local has been developed and made freely available on the Internet. The /bin/mail program is relatively complex software, serving both as a mail delivery agent and a user interface, allowing users to send and read E-mail messages. Complex system software, like /bin/mail, is more likely to exhibit security vulnerabilities. The mail.local package was written to perform only one task: the delivery of mail to local users. It is comparatively small, and the code has been examined carefully by experts in the security community. While it has not been formally evaluated, it is probable that mail.local addresses all vulnerabilities currently being exploited in /bin/mail. For more information, see the file README in the directory ftp://coast.cs.purdue.edu/pub/tools/unix/mail.local/. _____________________________________________________________________________ CIAC wishes to acknowledge the contributions of the CERT Coordination Center in the construction of this bulletin. _____________________________________________________________________________ For emergencies and off-hour assistance, DOE and DOE contractor sites can contact CIAC 24-hours a day via an integrated voicemail and SKYPAGE number. To use this service, dial 1-510-422-8193 or 1-800-759-7243 (SKYPAGE). The primary SKYPAGE PIN number, 8550070 is for the CIAC duty person. A second PIN, 8550074 is for the CIAC Project Leader. CIAC's FAX number is 510-423-8002, and the STU-III number is 510-423-2604. Send E-mail to ciac(a)llnl.gov. Previous CIAC notices, anti-virus software, and other information are available on the Internet via anonymous FTP from ciac.llnl.gov (IP address 128.115.19.53). CIAC has several self-subscribing mailing lists for electronic publications: 1. CIAC-BULLETIN for Advisories, highest priority - time critical information, and Bulletins, important computer security information; 2. CIAC-NOTES for Notes, a collection of computer security articles; 3. SPI-ANNOUNCE for official news about Security Profile Inspector (SPI) software updates, new features, distribution and availability; 4. SPI-NOTES, for discussion of problems and solutions regarding the use of SPI products. Our mailing lists are managed by a public domain software package called ListProcessor, which ignores E-mail header subject lines. To subscribe (add yourself) to one of our mailing lists, send requests of the following form: subscribe list-name LastName, FirstName PhoneNumber as the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES, SPI-ANNOUNCE or SPI-NOTES for "list-name" and valid information for "LastName" "FirstName" and "PhoneNumber." Send to: ciac-listproc(a)llnl.gov not to: ciac(a)llnl.gov e.g., subscribe ciac-notes O'Hara, Scarlett 404-555-1212 x36 subscribe ciac-bulletin O'Hara, Scarlett 404-555-1212 x36 You will receive an acknowledgment containing address and initial PIN, and information on how to change either of them, cancel your subscription, or get help. _____________________________________________________________________________ PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained by sending E-mail to first-request(a)first.org with an empty subject line and a message body containing the line: send first-contacts. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes.

1 0

DONT READ -- Continuing James Donald flamewar
by Perry E. Metzger 17 Dec '03

17 Dec '03

DONT READ THIS UNLESS YOU GIVE A DAMN ABOUT JAMES DONALD'S "OPINION" OF UNIX -- HIT DELETE NOW. jamesd(a)com.informix.com says: > But my statement concerning internationalization and > resource files was correct. Nope, sorry. Posix defines these things called "Locales". They provide automatic and seamless support for things like changing currency symbols, date formats, fonts, etc. The X windows system has full support for internationalization in most of its widget sets, too. > I have made a little tour of people in my company who work on both > unix and Windows. Sorry that you don't work with people who know about these things, but ignorance is not equivalent to absence. Frankly, I have yet to see a single statement from you that actually bore some relationship to reality. The most devistating comment you seem to be able to come up with about why Unix is bad is that make -- an application that doesn't even come with DOS -- used to have some places where it required tabs. Perry

3 5

Wall Street Journal Article
by daleh＠ix.netcom.com 17 Dec '03

17 Dec '03

This may have been mentioned, if so please ignore. There was an interesting article in Thursday's Wall Street Journal calling for the end of anonymous communications on the Internet. It is on page B1 under the "Personal Technology" column and was written by Walter Mossberg (mossberg(a)wsj.com) who invites comment. Just a couple of quotes: "When forums operate under the cloak of anonymity, it's no differenct from printing a newpaper in which the bylines are admittedly fake, and the letters to the editor are untraceable." and "It <anonymous communications> makes it easier to spread wild conspiracy theories, smear people, conduct financial scams or victimize others sexually." He goes on to discuss the other two BIG problems on the Internet, those being "Incivility" (flaming for breach of netiquette) and "Censorship" (cancelling of spams). Dale H.

1 0

CIAC Bulletin F-09
by John Young 17 Dec '03

17 Dec '03

[Note: Document reformated for mailing by jya(a)pipeline.com. If in doubt contact CIAC for original: ciac.llnl.gov:/pub/ciac/bulletin/f-fy95/f-09.ciac.(doc).] ________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ _________________________________________________________ INFORMATION BULLETIN Unix /bin/mail Vulnerabilities January 27, 1995 1030 PST Number F-09 _________________________________________________________ PROBLEM: The Unix /bin/mail utility contains security vulnerabilities. PLATFORMS: DEC OSF/1 1.2, 1.3, and 2.0 DEC Ultrix 4.3, 4.3A, and 4.4 SCO Unix System V/386 Release 3.2 OS Version 4.2 SCO Open Desktop Lite Release 3.0 SCO Open Desktop Release 3.0 SCO Open Server Enterprise System Release 3.0 SCO Open Server Network System Release 3.0 Solbourne OS4.1x SunOS 4.x DAMAGE: Local users may gain privileged (root) access. SOLUTION: Apply appropriate vendor patch as described below. _________________________________________________________ VULNERABILITY ASSESSMENT The vulnerabilities in the /bin/mail program have been openly discussed in several Internet forums, and automated scripts exploiting the vulnerabilities have been widely distributed. These tools have been used in many recent attacks. CIAC recommends sites install these patches as soon as possible. _________________________________________________________ Critical Information about Unix /bin/mail Vulnerabilities The /bin/mail utility on several Unix versions based on BSD 4.3 Unix contain a security vulnerability. The vulnerability is the result of race conditions that exist during the delivery of messages to local users. These race conditions will allow intruders to create or modify files on the system, resulting in privileged access to the system. Below is a summary of systems known to be either vulnerable or not vulnerable. If your vendor's name is not listed, please contact the vendor or CIAC for more information. Vendor or Source Status ---------------- ------------ Apple Computer, Inc. Not vulnerable Berkeley SW Design, Inc. (BSDI) Not vulnerable Cray Research, Inc. Not vulnerable Data General Corp. Not vulnerable Digital Equipment Corp. Vulnerable FreeBSD Not vulnerable Harris Not vulnerable IBM Not vulnerable NetBSD Not vulnerable NeXT, Inc. Not vulnerable Pyramid Not vulnerable The Santa Cruz Operation (SCO) Vulnerable Solbourne (Grumman) Vulnerable Sun Microsystems, Inc. SunOS 4.x vulnerable Solaris 2.x not vulnerable Patch Information ----------------- DEC The /bin/mail patch is a part of a comprehensive Security Enhanced Kit that addresses other security problems as well. This kit was released on May 17, 1994 and was described in DEC Security Advisory #0505 and CIAC Notes 94-03. OSF/1 users should upgrade to a minimum of version 2.0 and install Security Enhanced Kit CSCPAT_4061 v1.0. Ultrix users should upgrade to at least version 4.4 and install Security Enhanced Kit CSCPAT_4060 v1.0. Both kits are available from your Digital support channel or electronically by request via DSNlink. SCO Vulnerabilities in SCO's /bin/mail utility are removed by applying SCO's Support Level Supplement (SLS) uod392a. It is available via anonymous FTP from ftp.sco.com in the /SLS directory: Description Filename MD5 Checksum ----------- ------------ -------------------------------- Disk image uod392a.Z 2c26669d89f61174f751774115f367a5 Cover letter uod392a.ltr.Z 52db39424d5d23576e065af2b80aee49 Solbourne Grumman System Support Corporation now performs all Solbourne software and hardware support. Please contact them for further information: E-mail: support(a)nts.gssc.com Phone: 1-800-447-2861 FTP: ftp.nts.gssc.com Sun Sun has made patches available to remove vulnerabilities in /bin/mail. These patches address all vulnerabilities CIAC has seen exploited to date, and CIAC recommends they be installed. However, the patches will be updated again in the near future to remove additional vulnerabilities that have recently come to light. CIAC will announce the availability of the new patches when they are released. The patches may be obtained from your local Sun Answer Center or through anonymous FTP from sunsolve1.sun.com in the /pub/patches directory: SunOS Filename MD5 Checksum ------- --------------- -------------------------------- 4.1.x 100224-13.tar.Z 90a507017a1a40c4622b3f1f00ce5d2d 4.1.3U1 101436-08.tar.Z 0e64560edc61eb4b3da81a932e8b11e1 Alternative Solution -------------------- For those sites unable to obtain a vendor patch From owner-cypherpunks Fri Jan 27 13:19:28 1995 Return-Path: <owner-cypherpunks> Received: by toad.com id AA15273; Fri, 27 Jan 95 13:19:28 PST Received: from gateway.informix.com by toad.com id AA15259; Fri, 27 Jan 95 13:19:22 PST Received: from informix.com (infmx.informix.com) by gateway.informix.com (4.1/SMI-4.1) id AA10439; Fri, 27 Jan 95 13:19:16 PST Received: from carbon.informix.com by informix.com (4.1/SMI-4.1) id AA02110; Fri, 27 Jan 95 13:19:08 PST Received: by carbon.informix.com (5.0/SMI-SVR4) id AA00461; Fri, 27 Jan 1995 13:19:01 +0800 Date: Fri, 27 Jan 1995 13:19:01 +0800 From: jamesd(a)com.informix.com Message-Id: <9501272119.AA00461(a)carbon.informix.com> Subject: Oops, Correction: one big error in "Even more unix holy war." Apparently-To: perry(a)imsi.com Apparently-To: sdw(a)lig.net Apparently-To: wmo(a)digibd.com Apparently-To: cypherpunks(a)toad.com Content-Length: 2646 Sender: owner-cypherpunks(a)toad.com Precedence: bulk I wrote: > The great strength is of course symbolic debugging -- you can > single step your compiled code, and see it displayed symbolicly, > with the symbols and statements of your source code, > and with the contents memory displayed in terms of your > source code variables. On this I was of course totally wrong: Unix has symbolic debugging equal to DOS/Windows. I was under the false impression that it only had C code interpretation. This is an error -- what I said was true for C++, but then in Windows we too are forced to primarily use interpretation to debug C++. C++ symbolic debuggers are not up to acceptable capabilities in either system. Sorry. But my statement concerning internationalization and resource files was correct. Unix has no equivalent of App Studio, etc. I have made a little tour of people in my company who work on both unix and Windows. I (fortunately) work primarily on Windows, as you may have guessed. The company I presently work for is making a tool they call Window Painter. This is in some respects similar to App Studio. It works with their unix database language. But it is no App Studio, as the unix folk who are working on it freely admit, those few of them that have used App Studio. Most of my correspondents had replies along the lines of "Huh -- internationalization -- what source code tools could possibly help you with internationalization." Others listed irregular bands of random unix tools which are essentially irrelevant to the problem of internationalization. Most international unix programs have string files that the compiled program refers to a string by a number, and a font size by a number, and the position of the button on screen by a number -- site customizable information, Xdefaults, *.cfg This is functionally equivalent to the Windows Resource file, in that in principle one can keep translatable elements separate from source code. But is certainly not equivalent in ease of use. One can do the job, but in essense one does it by hand. Resource files, and dialog box editing tools such as App Studio, provide a clean separation between visual user interface elements that typically require translation, and functiona code that does not. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd(a)netcom.com

1 0

Even more unix holy war. Was "Clinton freezes U.S. assets .."
by jamesd＠com.informix.com 17 Dec '03

17 Dec '03

And did I mention that in DOS you can type: dir filename /s if you suspect that filename is in a subdirectory somewhere and you want the computer to find it for you, but in unix you type: find . -name filename -print but the entertaining thing is that if you type find . -name filename find then merrily goes forth, searches for the file -- which takes an extraordinarily long time, much longer than on my DOS machine, and then, cheerfully throws away what it has found, no warnings, no error message, no explanation. find thinks to itself "Gee, the user asked me to find the file, but he did not tell me to do anything with the information, so, I guess he just wanted me to exercise the network and the hard drive for five minutes or so." And did I mention "curses" You are spared. I will not mention "curses". And did I mention SUID. Well fortunately SUID has already been mentioned by other folk in the "Clinton freezes .." thread. And did I mention that unix has no less than seven families of metasyntactic operators, each of them different from and clashing with the others, that these families follow no logical order of substitution that I can figure out. Yeah, I know, that is what makes the unix shell so powerful. It is remarkably similar to what makes a chainsaw so powerful. It is very good at cutting your fingers off. And once again, I wish to remind you that the unix "make" utility used to treat spaces as semanticly different from tabs. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd(a)netcom.com

3 2