precedence: bulk
Subject: RISKS DIGEST 19.64

RISKS-LIST: Risks-Forum Digest  Wednesday 1 April 1998  Volume 19 : Issue 64

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. *****

 Contents: [Gap between issues due to travels, expectations of 1 April, etc.]
Funding for a new software paradigm (Douglas Moran)
Quantum computer cracks crypto keys quickly (Andrew)
The Computer Anti-Defamation Law (PGN)
Y2K: British Government moves to save civilisation as we know it (Nick Brown)
Y2K and The Aviation Industry (Mike Ellims)
Worried about Y2K?  Now there's D10K! (Edupage)
It's British Summer Time again... (Nick Rothwell)
Crossing that bridge to the Year-2000 problem (Edupage)
Microsoft EXCEL date error (yeeting)
Gore congratulates 71-year-old senator on birth of twins (Aydin Edguer)
Ron Rivest's nonencryptive Chaffing and Winnowing (Mich Kabay)
EMI and TWA 800 (original author unknown)
Phone scam alert: Social Engineering 101 (PGN)
9GB Cornell University Spam (James Byers)
CFP, Research in Intrusion Detection (Phillip A. Porras)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Wed, 1 Apr 1998 -8:00:00 -0800
From: Douglas Moran <[email protected]>
Subject: Funding for a new software paradigm

(Washington, DC, press release by IP Newswire, 1 April 1998) The Defense
Advanced Research Projects Agency (DARPA) today announced a major new
initiative in software engineering.  F.P. Rivers, program manager for the
initiative, said that it addresses a major problem facing the US military:
that much of current information technology is too "compute-intensive" to be
deployed where it is most needed -- at the small unit or even individual
soldier level.

This initiative has its origins in a fortuitous observation: Rivers and
several colleagues noticed that users on the most widely used platform --
Windows 95 -- were routinely presented with messages that an unknown
unrecoverable error had occurred, and that these users just as routinely
ignored those messages.  "This occurred not just in casual use, but also in
mission-critical operations."

Rivers said, "Once we started thinking about these messages not as a help,
but as a hindrance, several other observations came together."  In a typical
program, 40% to 80% of the code is devoted to error detection and error
handling.  "Software bloat" -- the ever increasing size of programs -- has
been blamed on programmers adding more and more features, but could also be
blamed on all the error handling associated with those features.  To make
matters worse, multiple studies had shown that much, if not most, of the
error-handling code was never tested.  Sometimes this was because of time
and budget pressures; sometimes the potential errors were so obscure and
complex that the situations were too difficult to create "in the lab".  This
research was backed up by actual experience: error-handling code was often
found to have significant errors.

Rivers summarized, "So, the typical program is overloaded with code that is
rarely used, that may not work, and whose output is likely to be ignored
anyway."  He concluded, "With this code removed, programs will be
dramatically smaller and will run somewhat-to-noticeably faster."

Many software developers, including several major vendors, have already
taken some tentative steps in this direction, having recognized pieces of
the problem, but without grasping the "big picture".  Rivers said he expects
this new approach, dubbed "Fault-Oblivious Computing", to quickly become the
dominant software-engineering paradigm.  He acknowledged that there were
small highly specialized segments where fault-tolerant computing and
program verification would still be of value.  A major component of this
initiative will be to develop tools to automatically identify and remove
unneeded error-handling code from existing applications.

The success of this approach would be be bad news for memory-chip
manufacturers, who are already hard-hit by decreased demand.

 [Perhaps Fault-Oblivious Computing could be used to help with the Y2K
 problem, getting rid of all those gratuitous date comparisons!!!  PGN]

------------------------------

Date: Wed, 1 Apr 1998 -05:00:00 -0500
From: [email protected]
Subject: Quantum computer cracks crypto keys quickly

A small team of researchers has succeeded in building a prototype of
the so-called "quantum computer" that can factor large numbers quickly
and defeat public-key cryptosystems.

The researchers cracked the DES-IV-1 challenge, revealing the message
"Can't anyone around here keep a secret?"

Since the new computer is based on superconducting quantum interference
devices, it is not bound by conventional temporal limits on computation. In
fact, the researchers were able to use their system to crack challenges that
had not yet been created.  These future secret messages included, "God in
Heaven, what have we done?" and the cryptic "tsopyadslooflirpanasisihtsey"
-- which clearly shows that future challenges are going to use multiple
layers of encryption.

President Clinton congratulated the researchers, but said that he was
considering a proposal to ban the export of quarks from the United States
until the NSA could implement a quark escrow system, by which each quark in
the universe would be uniquely numbered.

When asked if their invention would enable scientists to foretell the
future, the researchers pointed out that they can only decrypt messages that
are encrypted using certain methods that are known today.  Furthermore,
there is no way for them to determine if the messages that they receive are
authentic or if unknown people are sending false messages to confuse us.

"If only there were a reliable way to digitally sign a transmission,"
bemoaned one of the researchers.

------------------------------

Date: 1 Apr 1998
From: "Peter G. Neumann" <[email protected]>
Subject: The Computer Anti-Defamation Law

First there was the Texas cattlemen's legal action against Oprah Winfrey for
her remarks on TV about whether she would ever eat beef again after hosting
a program segment on Mad Cow Disease.  This suit was brought under the Texas
food antidefamation laws intended to protect that state's agricultural
products.  Winfrey was eventually absolved.

There was also Nike's threatened action against the Doonesbury comic strip
for drawing attention to the shoe manufacturer's alleged unsavory labor
practices in foreign sweatshops.  (A few years ago one week of Doonesbury
columns on Frank Sinatra was deemed offensive by the Italian-American
Antidefamation league and was omitted from some newspapers.)

Consequently, it is not surprising in our litigious society to hear of the
recent passage of the new Computer Anti-Defamation Law (CADL) protecting
computer system developers against people making public remarks detrimental
to computer programs and hardware.  Apparently, this law was in part a
response to the fact that specific cases of shoddy software are frequently
mentioned in the Risks Forum and other Internet newsgroups, which has
annoyed certain developers of chronically (and chronologically!) flawed
systems.  Although there have been reports that allegedly some of these
developers intentionally leave flaws in new software releases to incentivize
customers to upgrade to future versions, specifically naming purveyors
accused of such nasty business practices has explicitly been made illegal
under the new law.  In response, RISKS has considered the use of a private
coding scheme to refer to specific companies and products, but has discarded
that approach because it appears that the mapping from descriptors to
specifics would fall under the cryptographic escrow and key-recovery
regulations.

The Justice Department is considering whether the CADL can be applied to the
Cloverdale High School students (RISKS-19.60) who broke into Pentagon
computers and thereby made the U.S. Department of Defense look rather silly.
However, prosecution is considered unlikely -- not because there were no
financial gains and no extensive damage to the systems, but rather because
DoD surprisingly appears to be very grateful to the young hackers for
demonstrating how vulnerable the Pentagon systems really are.

A recent draft report from the U.S. General Accounting Office details the
extent to which Government computer systems currently fail to be Year-2000
compliant.  The GAO legal staff is currently considering whether public
release of this report would be in violation of the CADL, because there are
many references to specific noncompliant systems and their developers.  [We
may need a CADL prod to get this report out of their barn.]

Precisely because of ongoing difficulties in rectifying the Year-2000
Problem, the CADL has an exclusionary clause granting immunity to the
purveyors of the critical infrastructures (telecommunications, electric
power, transportation, etc.) in case their systems collapse at Y2K.  This
relief clause was included in hopes of inducing these purveyors to reveal
the extent to which the critical infrastructures are still Y2K-vulnerable --
which they have previously resisted disclosing in fear of subsequent
liability litigation.  There are unofficial reports that many of the
computer systems on which the critical infrastructures depend are in fact
not yet Y2K compliant and that many of them are not likely to be repaired in
time.  Rumors persist of massive outages of communications, utilities, and
transportation on or after 1 Jan 2000, but are very difficult to verify at
this time.  (The proof of the pudding is obviously in the eating, but many
of us may be dieting at that time.)  Additional legislation absolving
companies, COBOL programmers, and other Y2K specialists of all liability is
apparently also being contemplated, in hopes that they too will be more
likely to share their experiences -- although they would evidently still be
subject to the CADL, unless a Supreme Court challenge rules the CADL
unconstitutional.

Given the date of this message, it is not clear whether the CADL applies to
April-Fools' Day messages -- but it would seem highly likely.  Although such
messages always constitute risks unto themselves, they might be considered
beyond legal liability if they are suitably tasteful.  (We hope this one
is.)

 [Please observe that we have been extremely careful
 not to violate the CADL in writing this note.  PGN]

------------------------------

Date: Tue, 31 Mar 1998 14:02:41 +0200
From: BROWN Nick <[email protected]>
Subject: Y2K: British Government moves to save civilisation as we know it

According to BBC Radio, British Prime Minister Tony Blair has taken a
personal interest in the year 2000 problem, or "Millennium Bug" as it is
becoming known in UK media circles, to match the "Millennium Dome" being
built to celebrate the rollover to 2000.

An industry minister has been delegated to oversee a UKP 70 million (US$ 110
million) project to train people to fix year 2000 bugs.  The average amount
to be spent per trainee is apparently around UKP 1300 (US$ 1900).  The
minister, when interviewed, indicated that she thought this was adequate to
get people up to speed on the problem.

It was not clear from the 15-minute item whether the people to be trained
are existing programmers and analysts, or new to the computer industry.  UK
unemployment is running at about 6%, and Government statistics do not show
how many of these people have the potential to become experienced Cobol and
RPG programmers in eighteen months.

In the interests of balance, a professor from the University of Reading was
interviewed, stating that in his opinion, 99.99% (sic) of systems would be
unaffected.  He did not expand on this, so we don't know if he meant by
number of CPUs, dollar value of installed base, or megabytes of data stored.

The overall impression given by the item was that either the politicians, or
the journalists, or both, may not have completely grasped all the subtleties
of the issue.  Regular RISKS readers may be forgiven for not falling off
their chairs at this revelation.

Nick Brown, Strasbourg, France.

------------------------------

Date: Tue, 31 Mar 1998 14:28:34 +0100
From: Mike Ellims <[email protected]>
Subject: Y2K and The Aviation Industry

The *Guardian* ran a story on 25 Mar 1998 on some of the effects of the Y2K
bug in the aviation industry.

Some of the more interesting points include the following;

- Parts of the world could be declared no-go areas including Africa,
 South America and parts of the United States.

- Lloyd's say they will withdraw cover for airlines that did not adapt
 systems before 2000.

- The U.S. Federal Aviation Administration has said 20 of its computer
 systems are not ready to cope with the changes.

- The International Federation of Airline Pilots have been holding meetings
 to discuss a possible boycotts of some airports.  But they commented that
 in some parts of the world there was no probability of being hit by the bug
 because they are so far behind the rest of the world that they don't even
 have basic computer systems.

As a footnote they give the air-crash loss figures for 1997 at 375 million
pounds, with 22 crashes involving western built aircraft.  The figure so far
for 1998 is 166 million pounds.

 [A completely unrelated risk involves finding you don't have any floppy
 discs to transfer the risk submission from home to work, as all the floppy
 discs used for that purpose are still at the office...]

Mike Ellims - Pi Technology - [email protected]
www.pi-group.com -  +44 (0)1223 441 256

------------------------------

Date: Thu, 26 Mar 1998 19:00:13 -0500
From: Edupage Editors <[email protected]>
Subject: Worried about Y2K?  Now there's D10K!

Experts predict financial software may go haywire if the Dow Jones
Industrial Average tops 10,000.  Many software programs are designed to
handle only four-digit Dows, says one software designer, who says that
concern over the D10K problem soon "will spawn the usual parade of
opportunists" to fix the bug.  (*Wall Street Journal*, 26 Mar 1998;
Edupage, 26 March 1998)

 [... "if" it tops 10K?  Is anyone dow-ten' that Dow10K will occur?  PGN]

------------------------------

Date: 30 Mar 1998 17:22:10 -0000
From: Nick Rothwell <[email protected]>
Subject: It's British Summer Time again...

This spring's round of clock complications prompted me to dig through
the archives to look for an article I remembered on this topic
(http://catless.ncl.ac.uk/Risks/18.03.html#subj2).

I came in this beautiful Summer Time morning (after paying my bill for
weekend airport parking which overcharged me by one hour - but I digress) to
find all our Linux boxes running with the correct (Summer) time. I rebooted
my Linux workstation to NT, and manually set the time forward one hour. On
rebooting to Linux again, the time was again advanced by one hour.

Since Bruce Wampler didn't draw any conclusions in his article, I thought
I'd try. Our Linux boxes are configured to regard the CMOS clock as
permanently set to UTC. Since Linuxes understand the Summer Time rules our
machines happily migrated. However, NT (whether shifting zones manually or
automatically) seems to insist on keeping the CMOS clock set to local
time. Obviously, a reboot from Linux to NT and back to Linux is going to
leave the latter one bogus hour ahead as NT has advanced the CMOS clock as
well.

It's possible that Linux can be told to regard the CMOS clock as local (and
possibly to update it when necessary), but this suggests all sorts of
horrible race conditions: what if a Linux is rebooted shortly after it's set
the CMOS clock forward? How does it know it's done it?  If it marks the file
system in some way, what if one reboots from a different volume?

Quite clearly, the only sensible option is to have the hardware clock run in
contiguous UTC, with the software making timezone interpretations. Perhaps
unsurprisingly, this is the thing which NT cannot be persuaded to do. A
colleague suggests that backwards compatibility requires a local-time CMOS
clock for old applications; I can't think of any other explanation.

My dual-boot machine has three SCSI disks, so that the NT and Linux
environments are kept as separate and immune from interference as is
possible. Even so, they manage to interfere over the only other fragment of
mutable hardware state in the entire machine, a few bytes of battery-backed
RAM.

I just wanted to be the first to report this spring's set of date
complications. (Any earlier messages with dates stuck on GMT don't count...)

Nick Rothwell, CASSIEL  http://www.cassiel.com

------------------------------

Date: Thu, 19 Mar 1998 18:59:22 -0500
From: Edupage Editors <[email protected]>
Subject: Crossing that bridge to the Year-2000 problem

With $4.7 billion budgeted this year and next for solving the "Year 2000"
problem (when many computers will be unable to distinguish in which century
they are crunching numbers), the current progress report from federal
agencies is: only 35% of computer software systems critical for agencies to
perform their missions have been checked and fixed, with 3,500 critical
systems remaining in need of attention.  In testimony before two
subcommittees of Congress, an official of the General Accounting Office
summed up the situation by saying: "It is unlikely that agencies can
complete this vast amount of work in time."  No one knows the full scope of
the problem, because it is not possible to identify which systems are in
fact critical: a seemingly minor system will be critical if major systems
will not run without it.  (*The New York Times*, 19 Mar 1998; Edupage, 19
March 1998}

------------------------------

Date: Sun, 29 Mar 1998 04:10:54 -0500
From: "[email protected]" <[email protected]>
Subject: Microsoft EXCEL date error

Microsoft EXCEL version 6.0 ("Office 95 version") and version 7.0 ("Office
97 version") believe that year 1900 is a leap year.  The extra February 29
cause the following problems.

1)  All day-of-week before March 1, 1900 are incorrect;
2)  All date sequence (serial number) on and after March 1, 1900 are incorrect.
3)  Calculations of number of days across March 1, 1900 are incorrect.

The risk of the error will cause must be little.  Especially case 1.
However, import or export date using serial date number will be a problem.
If no one noticed anything wrong, it must be that no one did it that way.

 [If Y2K brings you back to 1900, that will be an added goody.  PGN]

------------------------------

Date: Mon, 23 Mar 1998 18:46:56 -0500 (EST)
From: Aydin Edguer <[email protected]>
Subject: Gore congratulates 71-year-old senator on birth of twins

Someone in Vice President Al Gore's office staff moused the wrong icon,
resulting in a letter to U.S. Sen. Daniel Moynihan (D-NY) congratulating him
on the birth of twins, instead of a letter congratulating him on his 71st
birthday on 16 Mar 1998.  "Tipper joins me in sending our warmest
congratulations and best wishes to you. We know that everyone close to you
shares the excitement of the new additions to your family."  [signed "Al".]
A new letter followed when the mistake was reported.

Tony Bullock, Moynihan's chief of staff, said that "Sen. Moynihan sent a
note to Gore's office saying that in 71 years he never had a birthday
present that gave him so much joy or laughter."  [Source: 1998 Nando.net and
The Associated Press, 22 Mar 1998,
http://www.nando.net/newsroom/ntn/politics/032298/politics7_11530.html]

 [Twins, eh?  A Moyninhand is worth two in the Bush Administration.  PGN]

------------------------------

Date: Sun, 22 Mar 1998 13:23:07 -0500
From: "Mich Kabay [ICSA]" <[email protected]>
Subject: Ron Rivest's nonencryptive Chaffing and Winnowing

Ronald Rivest has posted an interesting new model for maintaining
confidentiality without using encryption:

Chaffing and Winnowing: Confidentiality without Encryption

       Ronald L. Rivest
       MIT Lab for Computer Science
       March 22, 1998

See <http://theory.lcs.mit.edu/~rivest/chaffing.txt> for full details.

The method has the following key points:

* Sender and receiver desiring confidential communications agree on a
basis for computing message authentication codes (MACs);

* Sender breaks message up into packets and authenticates each packet
using the agreed-upon MAC algorithm.

* Sender introduces plausible "chaff" text, comparable to true message,
and generates random MACs for these packets.

* Receiver with authorized method for verifying MACs can distinguish
real packets ("wheat") from chaff by checking MACs and discarding chaff.

* Eavesdroppers, lacking a method for authenticating MACs, cannot
distinguish wheat from chaff.

This method of enhancing confidentiality would not seem to qualify for
regulation under the Export Administration Regulations of the U.S.
Department of Commerce, nor would current proposals by the FBI and other
elements of the Administration for mandatory key recovery appear to be
applicable.

M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education, International
Computer Security Association (Carlisle, PA) <http://www.icsa.net>

 [Ron Rivest has a later version of the document than that which Mich saw
 when he wrote this, and has added some further clevernesses.  This is
 really a very nifty piece of research.  Incidentally, Ed Felten notes that
 he found a potential inference exploitation by monitoring packet
 acknowledgements, and has a fix that does not seriously detract from the
 advantages.  PGN]

------------------------------

Date: Wed, 25 Mar 1998 18:25:48 +0000 (GMT)
From: Lloyd Wood <[email protected]>
Subject: EMI and TWA 800 (original author unknown)

 [Multiply forwarded, original author apparently lost.  PGN]

The April 9 _New York Review of Books_ has published a long special
supplement, "The Fall of TWA 800: The Possibility of Electromagnetic
Interference," by Elaine Scarry, a noted author and Harvard professor:

   http://jya.com/twa800-emi.htm  (128K with 3 images)

The article closely examines the possibility of electromagnetic interference
in TWA 800's controls, comm, and black boxes by activities of the ten US
military planes and ships in the vicinity which were heavily equipped for
electronic warfare and were conducting tests of the gear.

It is reports on what is publically known about the EM armaments of planes
and ships in the vicinity, about secret EM weapons and defenses, the several
dozen military and commercial planes that have crashed due to EMI, military
studies of long-standing EM hazards which will not be released to crash
investigators, current research in EMI and what scientists in the field
think about the possibility of EMI causing the fall of TWA 800.

It calls for the military to release its classified EMI research to NTSB
investigators, and short of that, for the servicemen and women on the planes
and ships at the scene to tell what they know. It asks Congress to order
military cooperation.

<[email protected]>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641

------------------------------

Date: Thu, 26 Mar 1998 11:10:43 PST
From: "Peter G. Neumann" <[email protected]>
Subject: Phone scam alert: Social Engineering 101

Here is a memo sent to me privately [slightly edited for clarity]:

The following Phone Scam Alert was reported in Canada by IM, We need to be
aware of this same situation in the US.

A person receives a telephone call from an individual identifying
himself/herself as a Technician who is running a test on the telephone lines.

They state that in order to complete the test, you should touch nine (9),
zero (0), pound sign (#) and hang up.

By pushing 9-0-# you end up giving the individual that called you access to
your telephone line and allows them to place a long distance call, which
appears on your bill.

This works best with computer based telephone systems such as the one in
Baltimore.  Apparently, this scam has been originating from local jails and
prisons.  Be cautious of this type of requests for people claiming to be
Phone Techs, Copier Techs, and Fax Repair persons.

------------------------------

Date: Thu, 19 Mar 1998 22:04:57 -0500
From: James Byers <[email protected]>
Subject: 9GB Cornell University Spam

Earlier this month, a Cornell University organization spammed the campus
with what amounted to 9GB of mail in the span of a few hours.  The
organization legitimately obtained a list of the e-mail addresses of
approximately 6100 on-campus students.  They proceeded to send out a message
with the entire block of addresses in the To: field, creating a 290K header.
This message provoked four angry replies to the entire group, 290K header
intact.  Needless to say, the incident caused a severe spike in disk usage
on the two Cornell postoffice machines.

 Anyone care to wager how long it will be before this list is in the
 hands of some commercial mass-mailer?

James Byers - [email protected] - http://www.people.cornell.edu/pages/jwb19

------------------------------

Date: Fri, 27 Mar 1998 17:37:47 -0800
From: "Phillip A. Porras [(415) 859-3232]" <[email protected]>
Subject: CFP, Research in Intrusion Detection

                 The Journal of Computer Security
                         CALL FOR PAPERS
                  Research in Intrusion Detection

There has been a recent resurgence in efforts within the intrusion-detection
research community to investigate and extend intrusion-detection technology
to larger distributed computing environments, including work to address such
issues as scalability, interoperability, distributed correlation, dynamic
deployment, and autonomous operation. Among such efforts has been work
involving the cross-pollination of intrusion-detection research with other
communities, such as the information retrieval and network management
communities.  In addition, interest has arisen in applying
intrusion-detection technology to new problem domains, such as fraud
detection in financial transactions and operations monitoring of
telecommunications infrastructures.

This special issue seeks papers that describe research beyond the scope or
orthogonal to what the commercial intrusion-detection community is producing.
The intent is to capture results from key efforts in the field, and to
understand the directions and motivations that are driving current and future
research in this area. Papers are solicited on all  aspects of intrusion
detection, including the extension of intrusion-detection techniques to new
problem domains, as well as the application of other techniques to intrusion
detection. Suggested topics include, but are not limited to

  o Active response capabilities and cooperative decision support
  o Cooperation policies and distributed correlation across administrative
    domains
  o Cross pollination of intrusion-detection techniques and applications
    with other disciplines
  o Formalization of activity modeling
  o Integration into large scale environments, including efficient methods
    for high-volume event analysis
  o Integration of intrusion-detection capabilities into existing network
    services, infrastructure, and management frameworks
  o Interoperability and reusability among intrusion-detection modules
  o Service-oriented intrusion-detection architectures (including work
    toward supportive services such as intrusion-detection management,
    dynamic registration, event collection, results interpretation)

The selections for this special issue will consist of high-quality original
unpublished research, case studies and implementation experiences.  The full
Call for Papers is available at: http://www.csl.sri.com/jcs-ids-call.html ,
with papers due by 15 Jul 1998.

Editor of the Special Issue: Phillip A. Porras <[email protected]>,
 Computer Science Laboratory, SRI International, 333 Ravenswood Avenue
 Menlo Park CA 94025-3493; phone: 650-859-3232, fax: 650-859-2844

------------------------------

Date: 1 Apr 1997 (LAST-MODIFIED)  [no fooling!]
From: [email protected]
Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you.  Or use Bitnet LISTSERV.  Alternatively,
(via majordomo) DIRECT REQUESTS to <[email protected]> with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
  INFO     [for unabridged version of RISKS information]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues.  *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to [email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
  [volume-summary issues are in risks-*.00]
  [back volumes have their own subdirectories, e.g., "cd 18" for volume 18]
or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
  get illustrative.PS

------------------------------

End of RISKS-FORUM Digest 19.64
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.