Subject: RISKS DIGEST 12.42 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 30 September 1991 Volume 12 : Issue 42 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Dialup lottery (PGN) Space Station Software Hubris (David Bremner) Re: V-22 Osprey (Henry Spencer) Re: Risks of computerized typesetting (Lauren Weinstein, Gene Spafford) Re: Radio Shack computerized mailing list problem (John R. Levine, et al.) Re: eelskin wallets and magnetic cards (Robert Ullmann, et al.) Re: Have you tested your machine lately? (Bennet Yee, Henry Spencer) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Sat, 28 Sep 91 12:32:14 PDT From: "Peter G. Neumann" Subject: Dialup lottery A followup on the Nintendo Lottery noted in RISKS-12.41 is contained in an AP item from 28Sep91 regarding a Minnesota law forbidding minors from gambling: Lottery officials and lottery vendor Control Data Corp. of Bloomington say the game will have safeguards to prevent children from gambling, including personal passwords for users. I'm glad that solves the problem so easily. By the way, I will be East for a week for the National Computer Security Conference, where I expect to see quite a few of you. Among other things, Ken van Wyk (VIRUS-L and SEI.CMU) and I will be on a panel Tuesday on the risks of distributing security information electronically. That should be amusing, at least for the two of us. A few of you have commented on some funny spellings in the masthead first line. Please recall that on two-digit Wednesdays and Saturdays in September we have a line longer than 80 characters -- resulting in the issue number getting TRUNCATED unless I foreshorten the line a little. ------------------------------ Date: Mon, 30 Sep 91 12:10:51 PDT From: bremner@cs.sfu.ca (David Bremner) Subject: Space Station Software Hubris In the Fall 1991 issue of Graduate Computerworld ( A free publication consisting of promo articles on prospective employers ), there is an interview with Julius Gabriel, manager of software engineering at Spar Aerospace. Spar is doing the software for the Mobile Servicing Station; essentially a mobile version of the Canada-Arm. Gabriel notes that "The entire space station will be highly computerized, with a software program in excess of 10 million lines of code". Apparently the MSS will be a rather small fraction of the whole, about "half a million lines of code". Master of understatement, Gabriel notes that "Once its up there it's difficult to fix the software". The article notes that "Naturally, the entire software process adheres to rigorous standards such as the military 2167A standard". Gabriel makes some good points about the importance of software development methodology, but what worries me is the attitude that writing ( working ! ) 10 million line programs is a solved problem, that all we have to do is use Ada (TM AJPO) and mil-std 2167A, and everything will work fine. David References: Page 14, Fall 1991 _Graduate Computer World_ bremner@cs.sfu.ca ubc-cs!fornax!bremner ------------------------------ Date: Sat, 28 Sep 91 18:44:45 EDT From: henry@zoo.toronto.edu Subject: Re: V-22 Osprey (Wodehouse, RISKS-12.41) >consider the case in which the triple sensors are not "reverse-wired" but cross-wired (e.g. sensor 2 is connected to input 1 & vs). In this case, with "all good" everything is fine. If 3 fails all is ok. However if 1 or 2 fails, the other is reported failed, voted out... Things can get even more interesting if there is more than one set of wires to the sensors, e.g. for feedback control of some kind. The second Saturn V test launch had a double engine failure in the second stage that was traced to such a problem: one engine did indeed develop problems, but the "shut down" command from the control computer went to the neighboring engine instead. Henry Spencer at U of Toronto Zoology utzoo!henry ------------------------------ Date: Sat, 28 Sep 91 18:01:41 PDT From: lauren@vortex.com (Lauren Weinstein) Subject: Re: Risks of computerized typesetting This is a classic case where technology can render traditional publication proofing useless if the technology is used inappropriately without proper checks and balances. In the traditional publishing environment, the galley proof usually has a photographic relationship to the final product. "Blue line" proofs for books are normally made from the same negatives that are then used to create the actual printing plates. The whole point of the galley or blue line proof is to give the author(s) an accurate representation of the final appearance of their work for their approval. When authors are placed in the position of approving a "proof" that does *not* represent that actual output that will be used to create the final plates, much of the point behind having the proof in the first place is lost. In the case where a font happens to vary in an unexpected manner (as in the case under discussion) this can be a rather serious problem. Authors should refuse to sign off on their works until their publishers supply them with a physical proof (not just an online representation unless it is a direct scan of the actual proof itself) that accurately shows the final output from the correct output device, complete with all fonts in their final forms. --Lauren-- ------------------------------ Date: 29 Sep 91 01:33:01 GMT From: spaf@cs.purdue.EDU (Gene Spafford) Subject: Errata for "Practical Unix Security" As reported in RISKS-12.41, Simson Garfinkel described how a non-standard font set-up on a phototypesetter caused some problems with the printing of our book. What follows is the announcement O'Reilly & Associates (the publisher) has made about this error. No word yet on what they are going to do with (or to!) the shop that did the printing! We breathlessly await the third printing to see what goes wrong there. :-) O'Reilly & Associates has discovered that in the first printing of _Practical_UNIX_Security_ by Simson Garfinkel and Gene Spafford (June, 1991) a formatting error caused the grave quotes (`) in the shell scripts in our final PostScript files to be printed as forward quotes ('). Of course, this breaks the scripts and is certainly not what the authors, editor, or publisher intended. An errata sheet is available from the publisher that corrects these shell script examples and other minor technical errors found in the first printing. Please telephone O'Reilly & Associates at 800-338-6887 (US & Canada) to obtain a copy of this sheet. Alternatively, you may send email to steph@ora.com, to request a copy of the errata sheet -- be sure to include your surface mail address. We apologize for any difficulties these errors may have caused! ------------------------------ Date: 29 Sep 91 22:54:25 EDT (Sun) From: johnl@iecc.cambridge.ma.us (John R. Levine) Subject: Re: Radio Shack computerized mailing list problem Joseph Poirer writes about getting a receipt with someone else's name on it when he declined to identify himself at Radio Shack, and wonders if their computer system can't handle a transaction without a name. It turns out that this isn't a computer problem, it is simply a management problem. Radio Shack employees get a bonus if they capture more than 95% of their customer names, and the employees are reacting in a locally rational way to anonymous customers. Rat Shack has severe penalties for employees who make up names, but apparently using the wrong real name is so far OK. It is easy to ring up a sale with no name, I get them to do it all the time. Rat Shack claims they use the names only for their own mailing list which they do not sell, but at least one person has reported getting junk mail from other parties with the same distinctive misspelling as Rat Shack has. Personally, if they hassle me when I decline to give my name, I make one up. Sometimes when I'm in a bad mood, I make one up unprompted. Phooey. John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl [This incentive to capture your vita was also noted by a bunch of other contributors, several of whom noted this discussion went on earlier for some time in comp.dcom.telecom. I therefore omit a whole slew of similar responses. You will understand if I do not enumerate you all! PGN] ------------------------------ Date: 28 Sep 91 16:13:21 EDT From: Robert Ullmann Subject: re: eelskin wallets and magnetic cards Kraig Meyer [in RISKS 12.41]: "USC security also claims that keeping the card in an eel-skin wallet will erase the magnetic strip (anyone have any idea why this would be?)" This is an old Urban Legend, about eelskin (or snake, alligator, etc) purses and wallets. The explanation isn't some strange electro-magnetic effect of reptile skin. It is that such things often (usually?) have magnetic clasps! Apparently this has to do with the skin not having the mechanical strength of (e.g.) leather; where a mechanical clasp would tear the eelskin under stress, the magnetic clasp simply opens. -- Robert Ullmann [Not surprisingly, we have slithered down this path before, WAY BACK IN RISKS-6.25 and RISKS-8.04 (Jane Dunlop Smith)!!! However, we have some alert contributors who again noted the mag clasp. This time * trebor@foretune.co.jp (Robert J Woodhead) * dplatt@ntg.com (Dave Platt) * mauxci!eci386!drk@apple.com (David King) and * kent@sunfs3.bos.camex.com (Kent Borg) all had puns on electric-eel-skins. * Al Stangenberger noted the version that several women who carried magnetically encoded BART (subway) tickets in their eel-skin wallets noticed that the magnetic strips had been erased. Also noting the bogosity of the magnetic clasp effects were * henry@zoo.toronto.edu (Henry Spencer) and * richg@prodnet.la.locus.com (Rich Greenberg) ------------------------------ Date: Sat, 28 Sep 91 18:22:04 -0400 From: Bennet_Yee@PLAY.MACH.CS.CMU.EDU Subject: Re: Have you tested your machine lately? (Sandberg, RISKS-12.41) The fact that division by zero does not generate a fatal error but gives a special value is a property of IEEE 754. Likewise with 0/0 == ``Nan'' (Not a Number), etc. I won't repeat the arguments as to why this may or may not be appropriate, but if you'd look at the ``See Also'' section of the math(3M) man page, you'd see references to several papers that address the design -- Kahan (the principle designer of 754) is quite compelling as to why 754's behavior is most reasonable. Is this a risk of coding without being cognizant of industry standards? Coding to an internal model of the machine that doesn't match reality? >Also if you notice on the output that the results are different depending on if you optimize or not. The fact that your code outputs ``Nan'' when it should have given ``+Infinity'' or ``-Infinity'' is probably a compiler bug. From the excerpt of the output, it appears that the behavior *with* optimization turned on is correct. This is actually a little surprising, since typically the optimizer introduces bugs, not the other way around. A risk of testing/debugging only that which we think is hard/bug-prone and skimping on the rest? Complaining about the compiler/floating point hardware to your vendor would be quite appropriate; complaints about IEEE 754 should probably go to Kahan instead. :) Risks of blame misattribution? Bennet S. Yee Phone: +1 412 268-7571 Email: bsy+@cs.cmu.edu School of Computer Science, Carnegie Mellon, Pittsburgh, PA 15213-3890 ------------------------------ Date: Sat, 28 Sep 91 18:58:48 EDT From: henry@zoo.toronto.edu Subject: Re: Have you tested your machine lately? >We have an Alliant fx/800 computer... ... By default no action is taken on many of the exceptions. ... I do not know the exact reasons for this decision, it might have to do with performance, but who cares if the machine is fast if the answers are wrong? Very probably it's a performance issue. I don't have any detailed knowledge of the Alliant, but I do know that this is a generic problem with attempts to build seriously fast computers: if you want to move fast, you have to go pretty much in a straight line. Any situation where a departure from sequential flow might occur, *and where it has to occur in a predictable way*, incurs major complexity and potentially serious delays to make sure everything is synchronized just in case. Folks interested in such things should read "Putting UNIX on Very Fast Computers", by Mike O'Dell, in the Proceedings of the Summer 1990 USENIX Conference. Mike was Chief Computer Scientist at now-defunct Prisma, which was trying to build a Cray-class SPARC. (USENIX can be reached, e.g. about availability of proceedings, at office@usenix.org.) Henry Spencer ------------------------------ End of RISKS-FORUM Digest 12.42 ************************