precedence: bulk Subject: RISKS DIGEST 19.38 RISKS-LIST: Risks-Forum Digest Weds 17 September 1997 Volume 19 : Issue 38 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: Walking Away From the Medicare Computer Project (Edupage) Dyslexic Telephone Switch causes billing errors (Robert J. Perillo) Barranquilla airport smells a rat (Mich Kabay) GCCS Military Software fails Year 2000 Test (Paul Robinson) Leaked memo on Mondex hacks embarasses bank (Paul Gillingwater) Illinois being sued to keep information public (Anthony Stuckey) Hewlett-Packard glitch spews spam (Gary Grossoehme) New --faster-- Macs broke old code (John Paulson) Personal info gone astray (Ken Knowlton) GM car acceleration due to EMI (Don Rosenberg) Re: SOHO gives 1 hour advance warning to Solar storms (Bob Schuchman) Re: KAL801 and GPWS (Peter B. Ladkin) Re: FBI wants to ban the Bible ... (Merlyn Kline, Dick Mills, Matt Millar, Martin Gleeson) Re: @LARGE -- Spaf quote (Len Spyker) Java Date Problems (Howard Melman) Risks of bad assumptions: octal numbers (Matt Toschlog) Long is 4 bytes? Not any more... (Peter da Silva) Re: Y2K and C (Steve Sapovits) 1998 IEEE Symposium on Security and Privacy (Mike Reiter) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 16 Sep 1997 12:32:11 -0400 From: Edupage Editors Subject: Walking Away From the Medicare Computer Project (Edupage) The Clinton Administration has terminated the contract with GTE for a new computer system to handle Medicare because the current system (run by 72 private insurance companies around the country) proved to be so antiquated and complicated that they frustrated GTE's efforts. The Department of Health & Human Services has told GTE to "stop all work, make no further shipments, place no further orders and terminate all subcontracts." Medicare officials say they will now work on individual pieces of the system rather than attempting to do the entire project at once. (*The New York Times*, 16 Sep 1997; 16 September 1997) ------------------------------ Date: Tue, 16 Sep 97 18:14 EDT From: Perillo@DOCKMASTER.NCSC.MIL Subject: Dyslexic Telephone Switch causes billing errors Northern Telecom Ltd. stated last week that its widely used DMS-100 telephone switch caused numerous billing errors in many phone company central offices due to a software bug introduced during a software upgrade this summer. The software glitch caused the billing interface to become dyslexic and use the wrong area code in phone company Central Offices covering more than one area code. The software snafu was fixed after about a month of erroneous billings. Net Users calling their "fixed price" local access number found hundreds of dollars of overcharges on their telephone bills this summer. The local number was billed as a toll call with a different area code attached. To add to the confusion, customers were told by their local telephone company that the billing problem was with their long distance company or the Internet Service Provider (ISP). And these companies directed customers back to the local telephone company. Customers were refused an explanation but were finally told that it was a "System Error". Pacific Bell acknowledged that 167,000 Californians, mainly in the Bay Area's 415 and 510 area codes and 805 near Los Angeles, were billed $667,000 in unwarranted local calls. The problem was also reported by Nynex customers (now Bell Atlantic) in the New York City area. I do not understand why [more extensive] testing and some sort of independent review was not done by NorTel before they released the software upgrade? The local telephone companies should also have some sort of Quality Assurance program in place before they allow a contractor to upgrade software in their Central Offices? I also do not understand why the local telephone companies did not handle the problem better in terms of customer service, and inform all possible affected customer's of the problem? [References: Inter@ctive Week, "Net Users Overcharged in Glitch", by Louis Trager, 08-Sep-1997. Forbes Magazine, "Midsummer madness, New technology is marvelous, except when it isn't. System Errors", by Dan Seligman, 08-Sep-1997, page 234. ] Robert J. Perillo, CCP, Richmond, VA Perillo@dockmaster.ncsc.mil [disclaimers] ------------------------------ Date: Fri, 12 Sep 1997 22:25:08 -0400 From: "Mich Kabay [NCSA]" Subject: Barranquilla airport smells a rat A rat caused a short circuit on 12 Sep 1997 by urinating on a high-power cable at Barranquilla airport in Colombia. This knocked out communications between the control tower and incoming aircraft, and caused the airport to shut down for almost an hour. [Reuters, 5 Sep 1997] ------------------------------ Date: Mon, 15 Sep 1997 17:15:24 -0700 From: Paul Robinson Subject: GCCS Military Software fails Year 2000 Test In an article on the front page of the 15 September 1997 {Government Computer News}, it is noted that the Defense Department's Global Command and Control System (GCCS) failed when the date was rolled over to the year 2000. GCCS is used at 500 Department of Defense sites worldwide to provide a comprehensive battlefield operational picture. It replaced an older system in August 1996. The test was done on 1 Aug 1997 during the Joint Warrior Interoperability Demonstration (JWID), which is used to show off emerging technologies for use in Command, Control, Communications, Computers and Intelligence (C4I) operations. Eight countries, including Canada (which has purchased GCCS for evaluation purposes), are participants in JWID. There are 28 tests used, including setting the date and time close to midnight on 31 Dec 1999 and letting the clock roll over, as well as for 28 Feb 2000 and 2001. In 10 of the 28 demonstrations, software expired or machines froze. One system failed to recognize that there is a 29 Feb 2000. Another had to be rebooted and had erased every user account. The failure is believed to be due to the underlying operating system. GCCS, current version 2.2, runs on Solaris 2.5.1, Windows NT, and HP-UX 9.0.7 and 9.0.10. It is said that systems running on Solaris 2.3, 2.4 and 2.5 are not year-2000 compliant. The Hewlett-Packard Unix systems are said to be compliant and passed the test. According to Lt. Cmdr. Mark Harvey, technical director at the Defense Information Systems Agency (DISA) for the JWID program, "So anything that was running on HP Unix worked. Anything that had Solaris did not." JWID rejected claims that their software was at fault, stating that the problem is claimed to be on Solaris versions 2.5 and below. Sun questions whether the application is at fault. John Leahy, government markets manager for Sun Microsystems Federal pointed out that "Even if the operating system is year 2000 compliant, that doesn't automatically mean the applications that run on it are." He also said the problem is surmountable if the latest release - Solaris 2.6, which has year 2000 support - is used. But DISA plans to use Solaris 2.5 for GCCS Version 3.0 to be released in January 1998. ------------------------------ Date: Mon, 15 Sep 1997 10:34:09 +0200 From: P.Gillingwater@iaea.org Subject: Leaked memo on Mondex hacks embarasses bank The following URL purports to contain an interesting leaked report on the security of the Mondex model for electronic money, as analysed during the due diligence process by a bank. http://jya.com/mondex-hack.htm The Risks: 1) Is an internal memorandum really covered by Copyright, since it is not "published"? 2) Presumably, banks operate under an agreement with Mondex whereby they are obliged to not disclose any security weaknesses they find in such security products as Mondex. Clearly, banks are not acting in the best interests of their customers. The risk is that keeping such holes secret doesn't improve security. 3) Attempts to suppress information, such as threatening EFF Canada with legal action, tend to have the opposite effect. Paul Gillingwater Internet Systems Administrator International Atomic Energy Agency (http://www.iaea.org) [TNO's Ernst Bovenlander gave some details of these attacks at Eurocrypt 1997. A link exists during testing that permits the contents of memory to be output on the serial port. The link is then severed before release of the smartcard. The attack involves fusing the link together again. [[This is an offer you can re-fuse!]] At RSA 1997, Tom Rowley of National Semiconductor reported a similar attack using an ion beam to rewrite the link. Incidentally, on Paul's third point, security-by-obscurity is not very obscure once it has been widely promulgated. PGN] ------------------------------ Date: Wed, 10 Sep 1997 12:40:41 -0500 (CDT) From: astuckey@urbana.css.mot.com (Anthony Stuckey) Subject: Illinois being sued to keep information public I found out about this through an Associated Press article in the Champaign-Urbana News-Gazette. (http://www.news-gazette.com) http://www.sos.state.il.us/special/optout/optform.html People keep mentioning the relationship between government-collected data and privacy invasion. Here it seems that we have an official trying to protect privacy who may not be legally able to. ------------------------------ Date: Tue, 16 Sep 1997 15:52:19 -0400 (EDT) From: GaryG4430@aol.com (Gary Grossoehme) Subject: Hewlett-Packard glitch spews spam By Alex Lash, 15 September 1997 [Source not specified.] Excerpted. > Some Web surfers who requested more information about a Hewlett-Packard > (HWP) scanner got a bit more information than they needed--thousands of > e-mails more. Because of an error in a mailing list for information on > HP's ScanJet 5, subscribers to the list received e-mail every time someone > sent a message back to HP. The e-mail then snowballed as angry recipients > flamed the company asking to be taken off the list. [Everybody was getting everybody else's 'unsubscribe' message, an experience that must be common to all of you who subscribe to UNMODERATED groups. PGN] ------------------------------ Date: Wed, 10 Sep 1997 18:09:02 -0700 From: john paulson Subject: New --faster-- Macs broke old code >The symptom is: >* I launch Frontier. >* The splash screen appears, then closes. >* Frontier hangs. > >According to Dave Winer, Doug Baron has found the bug and a fix is >forthcoming! I'll be updating this page as soon as I know more. >From Doug: >I see what's going on. It's a bug directly tied to processor >performance; there's never been a processor fast enough to cause this >integer overflow before. > >What were we doing? When opening windows, we wanted a >processor-independent way to pace the zooming effect, one that could >time in fractional ticks. So we execute a simple loop, calling >GetTickCount, and determine a loops-per-tick factor. When zooming, we d >elay some number of loops between each drawing operation, enough to >consume 1/6 of a tick. > >Unfortunately, the loop counter was a short -- ooops! The new Macs can >loop, calling GetTickCount, more than 32767 times per 1/6 of a tick, >i,e. more than 32767*6*60 times per second. Not bad! > >We're working on a patched version. ------------------------------ Date: Mon, 15 Sep 1997 08:46:47 -0400 (EDT) From: KCKnowlton@aol.com Subject: Personal info gone astray At the Continental Airlines ticketing office some robot, mechanical or human, has folded someone else's mailed confirmation into my own. I am given: the name and address of a woman in Texas who, barely a week ahead of time, bought a single ticket for a flight to Oregon, the times and dates and flight numbers, her ticketing confirmation number, and her Visa card number except that the last four digits are X-ed out, for "security purposes." How often does this sort of thing happen? Does anybody complain? With such information as a springboard, what kinds of mischief or crime might a troublemaker parlay it into? Ken Knowlton ------------------------------ Date: Tue, 9 Sep 1997 08:46:03 -0400 From: Don Rosenberg Subject: GM car acceleration due to EMI You might want to take a look at the *Wall Street Journal*, 8 Sep 1997, page B10, in which one incident (among many) of sudden acceleration by a GM car was demonstrated (proven in court, after seven years) to come from electromagnetic interference. GM had 1,761 sudden acceleration incidents between 1973 and 1986, with 1,121 injuries, and 31 deaths. There is a possibility that the Audi 5000 incidents (300 accidents, with 175 injuries and 4 deaths between 1978 and 1986) had a similar origin. In the GM court case, the "expert witness showed that the Buick's cruise control was sensitive enough to be set off by simply running a power drill near the car." Don Rosenberg, Stromian Technologies [According to Peter Ladkin, this appears to be a demonstrated case, but it's also in an environment in which the RFI shielding requirements are not as rigorous. Cars do not have to be certificated the way aircraft do. Check out Peter Ladkin's item in RISKS-19.24 and his Web page, and also Helfrick's article and the bluecoat WWW page http://bluecoat.eurocontrol.fr Also, out of band, Ira Rimson provided a useful reference: Roy W. Krieger, "The Danger of Electromagnetic Interference with Aircraft Systems: laptop laibility?", 1994 Annual Seminar of the International Society of Air Safety Investigators (ISASI, 5 Export Drive, Sterling, VA, 20164, e-mail:isasi@erols.com). The paper deals with results of the RTCA Special Committee (SC)-156 and its limitations, as well as both scientific and anecdotal data subsequently developed. Although the paper was delivered prior to publication of a subsequent RTCA SC-177 report (in 1995), the paper contains excellent background material which could form the foundation for defining research needs. PGN ------------------------------ Date: Mon, 08 Sep 1997 17:19:40 -0500 From: Bob Schuchman Subject: Re: SOHO gives 1 hour advance warning to Solar storms (RISKS-19.37) I just noticed the subject in the msg from John W. Cobb in 19.37. It isn't SOHO that is to provide the "warning" of solar storms. It is the Advanced Composition Explorer (ACE), which was launched on Aug. 25th. There is a URL with more ACE information, including the "science Goals" of ACE. It's at http://www.gsfc.nasa.gov/ace/ace.html. Bob ------------------------------ Date: Mon, 08 Sep 1997 23:24:29 +0200 From: "Peter B. Ladkin" Subject: Re: KAL801 and GPWS (Kohl, RISKS-19.37) John Kohl, in a response to my assertion that incorrect barometric altimetry on approach has a `safe' direction, opines that > Higher is safe in regards to ground terrain, but not necessarily safe > regarding other aircraft but forgets that on approach (the context in which my statement was made), the airspace above the aircraft is kept free of other aircraft by ATC, as they are required to do to allow for a missed approach procedure. Secondly, I don't know any meaningful designation KAL (title). The name of the airline is Korean Air, and its designator is KE. The flight was KE801. Peter Ladkin ------------------------------ Date: Thu, 11 Sep 1997 11:38:09 +0100 From: Merlyn Kline Subject: Re: FBI wants to ban the Bible ... (Rivest, RISKS-19.37) This is reminiscent of a time a few decades ago when certain popular records could be played backwards to reveal hidden messages. At that time there was a movement seeking to make it illegal to record things backwards. Of course any sound is just another sound backwards and I have seen cabaret acts by entertainers who have trained themselves to speak backwards. Such legislation would be nonsense for exactly the same reasons as the proposed legislation against use of codes would be. Any of us who have served time at the customer interface (I have spent many happy hours giving technical support:) will also know that even apparently plain English can turn out to be an impenetrable code (e.g. 'There was no error message displayed' could mean 'the screen turned blue and there was so much text displayed that it is easier to deny it ever existed rather than try to remember what any of it said'). The risk here is in the failure to distinguish between imprecision, inaccuracy and generalisation. The legislators seek to prevent people from doing something they don't like but experience tells them that if they define that thing too precisely there will be an immediate loophole in the legislation because people will be able to achieve the same ends by an activity which is slightly outside the definition. The solution is to generalise by identifying what it is they are really trying to prevent. Instead they arbitrarily lower the degree of precision in their definition, resulting in inaccuracy rather than generalisation. The result is all too often a meaningless definition rather than an accurate generalisation. Eherway oday ouyay antway otay ogay odaytay? Merlyn Kline = merlyn@zynet.net ------------------------------ Date: Tue, 09 Sep 1997 18:23:45 -0400 From: Dick Mills Subject: Re: FBI wants to ban the Bible ... (Rivest, RISKS-19.37) I can think of an even more literal interpretation. Namely, that any device that can be used to communicate in any medium can be used to encrypt, and thus would be banned. I don't doubt that it is serious, but I am confused over the literal interpretation of the words. But in RISKS-19.36, John R. Levine seemed to close a long standing debate over whether literal interpretatation of law means that computers are fax machines and thus e-mail must be faxes. Which is it supposed to be? Should citizens attempt to read and interpret the literal text of written laws ourselves, or should we rely on lawyers to tell us what the words really mean. Perhaps we should we have a double standard. Get excited over the exact wording of proposed laws, but be passive about the exact wording of existing laws. Dick Mills http://www.albany.net/~dmills ------------------------------ Date: Mon, 8 Sep 1997 18:16 +0100 (BST) From: millar@cix.co.uk (Matt Millar) Subject: Re: FBI wants to ban the Bible ... (Rivest, RISKS-19.37) Could this be extended to foreign languages? Before I post a message in a language other than english do I have to check that someone in the FBI can speak that language? Computer languages? Anyone speak C++ here? Matt "... will inevitably lead to ..." - anyone without a coherent argument. ------------------------------ Date: Tue, 9 Sep 1997 13:18:40 +1000 From: Martin Gleeson Subject: Re: FBI wants to ban the Bible ... (Rivest, RISKS-19.37) The Risks of this go on and on: would information in languages that the FBI can't translate also be illegal? It could be argued that languages are elaborate "substitution codes". Martin Gleeson, Information Systems Development, The University of Melbourne. ------------------------------ Date: Sat, 13 Sep 1997 09:37:13 GMT From: redmond@iinet.net.au (len spyker) Subject: Re: @LARGE -- Spaf quote (RISKS-19.37) > One of the chapter-head quotes is from Gene Spafford: "Using encryption on > the Internet is the equivalent of arranging an armored car to deliver > credit-card information from someone living in a cardboard box to someone > living on a park bench." [PGN] If what you read in RISKS, on Internet networks and their nonsecurity with or without encryption, is accurate (and I don't doubt that), I would para phrase it the other way around: Using encryption on the Internet is the equivalent of arranging a bike courier to verbally deliver credit-card information from someone living in a home or company fortress to someone in an expensive shop on Park Lane. And a possible extra clarification Without encryption, the Internet is the equivalent of arranging for a gang of muggers to come into your own home. Len Spyker ------------------------------ Date: Mon, 8 Sep 1997 18:14:07 -0400 From: Howard Melman Subject: Java Date Problems (Ryan, RISKS-19.37) It may well be true that Java won't have a Y2K problem. But I've yet to find a version of Java that has working Date classes. Try creating a new GregorianCalendar() with no arguments and then setting it explicitly to Jan 27 1997 at 3:15pm (or any other time). If you inspect any of the other fields in the GregorianCalendar (e.g., DAY_OF_YEAR, DAY_OF_WEEK, DAY_OF_WEEK_IN_MONTH, AM_PM, HOUR, ZONE_OFFSET, or DST_OFFSET) you'll find they haven't been set. Or try creating a new GregorianCalendar object and calling getFirstDayOfWeek(). It returns 1 but should be 0 in a US Locale. You'll find other problems if you don't run in Pacific Standard Time. There is a bug in java.text.SimpleDateFormat.initialize(). SimpleDateFormat in an en_US locale initializes to PST (the first one listed in java.text.resources.DateFormatZoneData_en) not TimeZone.getDefault() which correctly (for me) returns EST (other fields correct for Daylight Savings Time). If you don't program Java, point your favorite Java enabled Web browser (e.g., Netscape 4.01 on NT, recent versions of the IE Java VM seem to have fixed this) at Intellicast's web site where they have a little Java clock showing the local time and the GMT time, e.g.: http://www.intellicast.com/weather/bos/nexrad/ You'll find the local time to be PDT if you are in the US whether you're in PDT or not. And in older versions of Java you'd find that the GMT time is off by an hour for DST. The risk? Don't assume that Y2K are the only date bugs you might have. Howard ------------------------------ Date: Wed, 10 Sep 1997 16:47:28 -500 From: "Matt Toschlog" Subject: Risks of bad assumptions: octal numbers (Re: Gunshannon, RISKS-19.37) [Sent by Chris Green at Matt's request.] Bill Gunshannon describes treating numbers with a leading zero as octal as "quite normal and completely intentional." That may be true if the reader is a C parser -- the C spec dictates this behavior. But the orginal case cited was a user input box on a web page. And though there's no "spec" for how a user interprets an input box, it's certainly the assumption of virtually everyone that numbers are in base 10. The RISK here is assuming that a person things like a compiler. Matt Toschlog, Outrage Entertainment ------------------------------ Date: Mon, 8 Sep 1997 13:48:01 -0500 From: Peter da Silva Subject: Long is 4 bytes? Not any more... (Re: Coats, Year 2038 problem) coats@mcnc.org wrote: > There is a substantial risk that systems from Sun, SGI, HP, and DG > will still use 4-byte integers for "long" in 2038. But not Digital: amanda:subsonic:s5 8 % cat demo.c #include main() { printf("%d\n", sizeof(long)); } amanda:subsonic:s5 9 % make demo cc demo.c -o demo amanda:subsonic:s5 10 % ./demo 8 Given the amount of code already ported to Digital UNIX, with few sizeof(long) problems, I hope that people will realize that the 4-byte long is long overdue for replacement. I've always thought it should have been 8 bytes on the VAX, myself. It would have made it easier for me porting my PDP-11 code that assumed sizeof(long) > sizeof(int), which had been the standard until, then. ------------------------------ Date: Mon, 08 Sep 1997 17:32:52 -0400 From: Steve Sapovits Subject: Re: Y2K and C (Rosenthal, RISKS-19.37) rosenthh@dialogic.com wrote: > >> ... a C "long" which is currently 4 bytes. When 64-bit operating systems > >> finally catch on there will be a lot of code to change when "long" > >> becomes 8 bytes, while the data on disk is still only 4. I missed the original point above, but it's not really accurate (at least in its snipped form). C doesn't claim a long is 4 bytes. The size of all the types is basically machine dependent. Yes, on most machines a long is 32 bits, but C doesn't decree that. > C is the only language I've ever used in which the *source* code isn't even > portable because such basic concepts as intrinsic datatypes are > indeterminate (and are *defined* as such in the original specification). > Does it worry anybody else that this is the language used by most people and > taught to most beginners? I suppose at least we're not teaching BASIC using > two-letter variables and GOTOs, but still . . . . I worry more that we're not training people how to program. While C may leave a lot to be desired, it certainly doesn't prevent one from solving these problems. I can't think of any language that doesn't allow you to write data to a disk in a binary format. Any ability to do that could be considered a problem since as machines progress the sizes and byte ordering of such binary data may change. Most people who care concerned about such issues solve them through proper design and programming. You can, for example, use typedefs in C to properly map sensitive data types to the appropriate base types so they can be easily changed when the software is ported. When writing data to files, you can use a canonical format such as text to avoid the problem mentioned above. Steve Sapovits WinStar Telebase (http://www.telebase.com) steves@n2k.com ------------------------------ Date: Sat, 6 Sep 1997 17:42:49 -0400 (EDT) From: Mike Reiter Subject: 1998 IEEE Symposium on Security and Privacy PRELIMINARY CALL FOR PAPERS for 1998 IEEE Symposium on Security and Privacy 3-6 May 1998, Oakland, California, sponsored by the IEEE Computer Society Technical Committee on Security and Privacy, in cooperation with The International Association for Cryptologic Research (IACR) (abstracted for RISKS) Papers and panel proposals must be received by 6:00 P.M. EST on Monday, 24 November 1997, sent to Paul A. Karger, Program Co-Chair, IBM Corporation Thomas J. Watson Research Center, 30 Saw Mill River Road Hawthorne, NY 10532, USA Please contact Paul Karger by electronic mail at secprv98@watson.ibm.com or by telephone at +1 (914) 784-7294, relating to the submission procedures. General Chair: Mike Reiter, AT&T Labs - Research, USA Vice Chair: John McLean, Naval Research Laboratory, USA ------------------------------ Date: 1 Apr 1997 (LAST-MODIFIED) From: RISKS-request@csl.sri.com 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 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 risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]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.38 ************************