Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
My sincerest apologies to those of you who received multiple copies of
RISKS-9.63. I keep breaking the mailing list up into smaller sublists, but for
the first time TWO of the sublists were victimized by the lurking SENDMAIL
flaw. I will try mailing this issue to the sublists sequentially, waiting for
each sublist to complete before going on to the next, just in case there are
competing effects. I have been putting out fewer issues in hopes of minimizing
your annoyance, but that is also counterproductive. So, please bear with me as
I try this issue serially over the sublists... Painful, but it might help!
By the way, the end of the AT&T "Official report" message in RISKS-9.63 had a
few trailing blank characters that overflowed the line and made the next line
look blank on my screen, which means that the undigestifiers probably gagged on
it and refused to recognize the following message separately. I try hard to
avoid that, but this one slipped through. For those of you who get RISKS as
individual messages, Oops. Sorry. :-(
PGN
Mark Bartelt, Hospital for Sick Children, Toronto mark@sickkids.utoronto.ca
416/598-6442 UUCP: {utzoo,decvax}!sickkids!mark
Group questions software's reliability after Bruce Accident
(Canadian Press)
A computer software error that released thousands of litres of radioactive
water at the Bruce nuclear station raises questions about the reliability of
software at the new Darlington station, Energy Probe says. "This spurious
software accident at Bruce Unit 4 should be regarded as a warning about
software safety in general," Tom Adams, utility analyst with the energy
watchdog group, said yesterday. But Ontario Hydro says the group is comparing
"apples to oranges."
The computers at Darlington have three backup systems that automatically shut
down the reactors in certain emergencies, spokesman Dave Stevens said. The
Crown utility says a software flaw caused last week's accident, when a
mechanical fuelling machine was loading and unloading fuel bundles into reactor
Unit 4 at the Bruce station at Kincardine, near Owen Sound. No one was injured
and neither workers nor the environment were directly contaminated by the
tritium-irradiated heavy water, which escaped from the reactor as steam.
Although Mr. Stevens said he did not know whether Hydro had anticipated such an
accident, he said the utility had contingency plans for the release of heavy
water.
A spokesman for the Atomic Energy Control Board, which regulates the safety of
the nuclear industry, described the accident as "very unusual and also very
significant" because of what could have happened. "It has the appearance of
something that could have been worse," Zygmund Domaratzki said in a telephone
interview from Ottawa. "If that fuelling machine had kept on going it would
have ripped the end of that channel," allowing the fuel bundles to tumble out,
Mr. Domaratzki said. With that kind of mishap, he said, "it wouldn't take much
to cause widespread contamination within the reactor building." As it was, the
accident cost Hydro time and money, he said.
Meanwhile, heavy water continued leaking from the Bruce reactor yesterday at
the rate of about seven litres per hour. Workers planned to remove 13 fuel
bundles from the damaged fuel channel and retrieve the fuelling machine, still
dangling on the face of the reactor. The unit is expected to be down for at
least six weeks.
Because two of the other three reactors at Bruce are still down, the giant
utility may have problems meeting demand if there is a severe cold snap.
Found in the British ``Guardian'' newspaper of 25 January 1990: ``The entire state police force in the New South Wales Australia, found itself driving illegal cars after an enthusiastic computer deregistered them, Paul Zucker reports on the Newsbytes online newsletter. The police were instructed to book themselves, or each other. ``The problem was cause by a high ranking officer (not named) who failed to pay illegal parking tickets. His unmarked car was registered to the police department. After statutory warnings were ignored, the computer program deregistered all cars belonging to the offender: that is, all cars belonging to the police department.'' It may be that I am still under the influence of Dijkstra's CACM article, but notice how the computer is given the human attribute "enthusiastic". Diomidis Spinellis, Imperial College, London.
posted recently (edited slightly): Subject: Fire and 753 controllers Date: 30 Jan 90 14:25:25 GMT [From: Neal Immega] Organization: Shell Development Company, Bellaire Research Center, Houston, TX Shell Development Co. had a fire in a SUN 4/280 when diodes on a Xylogics 753 disk controller overheated and caught fire. The plastic card guides on the Illmanite double wide to triple wide controller also appear to have burned and may have contributed to the damage of the two adjacent disk controller cards (which operated perfectly while burning!). Flames four inches high were coming out of the top of the card cage when the fire was extinguished. This problem could have been prevented if we had been notified of the 10/10/89 field change notice from Xylogics to make a free upgrade to all boards by adding a heatsink for the diodes. The new design has a bronze colored strip 1.5 inch wide running the length of the card. Xylogics said that I should have been notified by the distributor (CITA Technologies) and CITA says that they were not told of the problem. The Xylogics contact for this is Laurie Walker at 617-272-8140. She will need the serial number from the board (X plus 7 numbers from the back). Neal Immega Staff Geologist , Geology Research Shell Development Company, Bellaire Research Center (713) 663-2572 ...!rice!shell!immega immega@shell.com [This raises the interesting question how us poor users at the bottom of the food chain are expected to find out about safety-related problems.... Mark Seiden, mis@seiden.com, 203 329 2722]
I am surprised that no one has pointed to the [IMHO] real error committed by AT&T: that is, upgrading all of the ESS4s to the same s/w revision at the same time. This exposes the network to a single error, with consequences that affect the entire network simultaneously. To contrast, from personal experience: I run the internal mail network in Prime Computer, which runs SMTP mail on 3000 systems in 27 countries. I have been criticized for not being agressive in upgrading the revision of PDNmail (an RFC1090 implementation) to current release. My reason is that the network is much more robust running a range of different versions (much like Long-Lines was, before everything was ESSn, with DLL'd s/w: which is why this didn't happen before). Many of the systems run other software implementations entirely, which also helps. Except when those implementations are "ports" of the same software, witness the continuing generic sendmail problems. Not that anything is wrong with sendmail, per se, but there ought to be more independent implementations-from-specification. The resulting heterogenous network of systems is so robust that I can test new implmentations of PDNmail by replacing the mailer on the most heavily loaded system (!), and watching closely for several hours. (Not that I am generally advocating this sort of thing! "ah, Schickelgruber, you have a new version of the master S/W? It compiles, Ja? Sehr gut, load it on Hinsdale ... " :-) Systemic problems with new versions become apparent after only a few systems are using it in production service; and only affect a small part of the network, even if undiagnosed or uncorrected for long periods of time. Robert Ullmann, Prime Computer, Inc.
>From Telecom-Digest: Volume 10, Issue 59 and Risks Digest: 9.63
> Here's AT&T's _official_ report on the Martin Luther King day network
> problems, courtesy of the AT&T Consultant Liason Program.
> ...
> While the software had been rigorously tested in laboratory
> environments before it was introduced, the unique combination of
> events that led to this problem couldn't be predicted.
^^^^^^^^ ^^
Don't they mean "wasn't"? The rest of the report seems (to me) to be
reasonably detailed, well explained, and apparently honest, but this one little
dissemblance ruins the whole thing. Is there any justification for the
assertion that the prediction was (and is) _impossible_ in these circumstances?
— Bob Munck, MITRE Corporation, McLean VA
In RISKS 9.63, Olivier Crepin-Leblond provided a number of interesting conclusions regarding the A320 crash at Mulhouse-Habsheim. _Flight International_ also leaked the commission's findings, which accord heavily with what he translated. It should be noted, however, that while the engines were at comparatively high power settings at the time of impact, the flight path of the airplane was quite unusual — it approached the field from a high altitude, "dirty" (flaps and landing gear extended), and with engines at *flight idle.* It is entirely conceivable that the airplane was far behind the power curve at the point the flight crew decided to go around; moreover, this maneuver is unusual enough in of itself to bring into serious doubt the crew's judgement. The altimeter issue is also interesting, but has largely been applied to the incident after later experiences with altitude displays going haywire on IFR approaches (including one well-publicised incident into Zurich). In the crash, the visibility was unlimited VFR; at low altitudes in such weather, one does not pay much attention to the altimeter, anyway--even in airliners. The captain still insists that his flight instruments did him in. Lastly, I note with some amusement the captain's new place of employment. Australia has been undergoing a very bitter pilot's dispute. The largest airline recently fired all striking pilots (which is to say, all of its pilots) and has been recruiting heavily overseas, offering relatively senior positions to anyone with even marginal qualifications. Robert Dorsett Moderator, aeronautics Internet: rdd@rascal.ics.utexas.edu mailing list. UUCP: ...cs.utexas.edu!rascal.ics.utexas.edu!rdd
>The appendices provide extensive references to other publications, security
>organizations, anti-viral software sources, applicable (U.S.) state and
>Federal laws against computer crime, and detailed descriptions of all IBM and
>Apple Macintosh viruses known as of 1 October 1990.
^^^^ No, the authors aren't
psychic. I've been writing 1989 on all my checks for the past month, and now
I'm writing 1990 everywhere I should write 1989! I'm glad so many people found
this amusing....someday you'll grow old and senile too :-)
Gene Spafford, NSF/Purdue/U of Florida Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Please report problems with the web pages to the maintainer