December 2003 - cypherpunks-legacy

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: 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

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

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

Re: Wall Street Journal Article
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 11:39 AM 1/27/95, Dale Harrison (AEGIS wrote: >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. This Mossberg guy, to quote Mrs. Slocumb, really gets up my nose. With apologies to the last flamewar's participants and MicroSquish partisans, this bozoid monstrosity has historically demonstrated his cluelessness and is living proof that no one got fired by buying IBM *and* Microsoft. Every few weeks this clown shows up on the Paper of Record for the Plutocracy of the Planet and positively warps space with his inaccuracies. He probably learned to code in COBOL. He probably calls a microcomputer a "terminal". He probably calls a server a "host". He probably even has grey hair... ;-). The brain bleeds. The mouth froths. Somebody needs to feed this guy's email address to Detweiler with the "tip" that he's a tenticle of someone around here who's actually cluefull ... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

Oops, Correction: one big error in "Even more unix holy war."
by m5＠vail.tivoli.com 17 Dec '03

17 Dec '03

jamesd(a)com.informix.com writes: > 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. I hate to contribute to this silliness, but I can't let blatant errors like this pass. I debug reams of C++ daily on a wide variety of UNIX platforms. With real symbols. With real C++ expression evaluation an overload resolution. (I also get to use compilers that actually come close to supporting the language as defined by the ARM.) | GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5(a)tivoli.com> | | TAKE TWA TO CAIRO. ||| Tivoli Systems, Austin, TX: | | (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |

1 0