I just wrote:
> [...]
> --
> Michael Sokolov 2695 VILLA CREEK DR STE 240
> Software Engineer DALLAS TX 75234-7329 USA
> JP Systems, Inc. Phone: +1-972-484-5432 x247
> or +1-888-665-2460 x247
> E-mail: msokolov(a)meson.jpsystems.com Fax: +1-972-484-4154
Argh! Used the wrong sig file again! Here is the right one:
--
Michael Sokolov Harhan Computer Operation Facility
Special Agent 615 N GOOD LATIMER EXPY #4
International Free Computing Task Force DALLAS TX 75204-5852 USA
Phone: +1-214-824-7693
ARPA INET: msokolov(a)meson.jpsystems.com
I guess I'll keep bumping into this one until I set up separate mail addresses
for my two affiliations and subscribe to all lists from the right one... Sorry
about that.
John Rosenberg <jcrosenberg(a)earthlink.net> wrote:
> Recently I came into posession of a MicroVAX 4000 series machine at an
> auction, and the question now is: What do I do with the darned thing?
The right answer for you is the Quasijarus project. See its WWW page at:
http://minnie.cs.adfa.edu.au/Quasijarus/
The project has a mailing list to which I have already subscribed you. To post
to the list, send to quasijarus(a)meson.jpsystems.com. If anyone else wants to
subscribe, drop a line to quasijarus-request(a)meson.jpsystems.com.
--
Michael Sokolov 2695 VILLA CREEK DR STE 240
Software Engineer DALLAS TX 75234-7329 USA
JP Systems, Inc. Phone: +1-972-484-5432 x247
or +1-888-665-2460 x247
E-mail: msokolov(a)meson.jpsystems.com Fax: +1-972-484-4154
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id DAA86111
for pups-liszt; Thu, 13 Jan 2000 03:36:54 +1100 (EST)
On a recent expedition, I recovered some additional USENIX tapes:
Usenix 83
Usenix 87
Usenix 88
Usenix 89
Now, none of these are as "classic" as the current Usenix tapes in the
PUPS archive (by my searching, Usenix 77, 78, 79, 80, and 81.) Is
there perhaps some other on-line archive out there that would be
interested in copies of these tapes? My E-mails to various addresses
on www.usenix.org so far have left me with the impression that they
have no library of material older than 1993 and they have no interest
in older material, though I strongly suspect that I'm talking with all
the wrong people.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id DAA85888
for pups-liszt; Thu, 13 Jan 2000 03:04:56 +1100 (EST)
>From "John Rosenberg" <jcrosenberg(a)earthlink.net> Thu Jan 13 02:03:04 2000
Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id DAA85879
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 13 Jan 2000 03:04:29 +1100 (EST)
Received: from home (sdn-ar-001mabostP216.dialsprint.net [168.191.54.130])
by gull.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id IAA27448;
Wed, 12 Jan 2000 08:04:19 -0800 (PST)
Message-ID: <003f01bf5d16$a0ccc020$c469fea9@home>
From: "John Rosenberg" <jcrosenberg(a)earthlink.net>
To: <wkt(a)cs.adfa.edu.au>, "Unix Heritage Society" <pups(a)minnie.cs.adfa.edu.au>
References: <200001100540.QAA64928(a)henry.cs.adfa.edu.au>
Subject: New member
Date: Wed, 12 Jan 2000 11:03:04 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Kind greetings, all. I am a new member of the Society, and have been
delighted with the messages I have seen.
Recently I came into posession of a MicroVAX 4000 series machine at an
auction, and the question now is: What do I do with the darned thing? It was
really a bargain I could not pass up; and I'm pretty sure that it is in
entirely usable condition. (I still have to fully test it.)
Suggesetions? I have no Web site to run, even if I did want to spend the
money on the required infrastructure & maintenance.
Much obliged in advance, and again, I am more than happy to have joined the
Society.
John Rosenberg
33 Pond Ave. #601
Brookline, MA 02445
617-277-7868
jcrosenberg(a)earthlink.net (generally preferred)
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id DAA86073
for pups-liszt; Thu, 13 Jan 2000 03:33:14 +1100 (EST)
Hi All,
With a lot of help from Norman Wilson, Tim Shoppa and Dennis Ritchie
himself, I've been able to modify my Apout emulator to run the 2nd Edition
UNIX C compiler binaries. Using these, I've been able to recompile the
`last1120' C compiler described by Dennis on his web page at:
http://cm.bell-labs.com/cm/cs/who/dmr/primevalC.html
The new version of Apout, as always, is available at:
ftp://minnie.cs.adfa.edu.au/pub/PDP-11/Sims/Apout/
I've also put the source code to the last1120 C compiler in UnixBins/
Soren also pointed out a code problem stopping compilation on NetBSD,
which has been fixed.
Cheers all,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id CAA74341
for pups-liszt; Tue, 11 Jan 2000 02:10:03 +1100 (EST)
>From "Daniel A. Seagraves" <DSEAGRAV(a)toad.xkl.com> Tue Jan 11 01:08:33 2000
Received: from toad.xkl.com (toad.xkl.com [192.94.202.40])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id CAA74301
for <pups(a)minnie.cs.adfa.oz.au>; Tue, 11 Jan 2000 02:09:41 +1100 (EST)
Date: Mon, 10 Jan 2000 07:08:33 -0800
From: "Daniel A. Seagraves" <DSEAGRAV(a)toad.xkl.com>
Subject: I need help rewriting the 2.11BSD bootblock...
To: pups(a)minnie.cs.adfa.oz.au
Message-ID: <13514475029.13.DSEAGRAV(a)toad.xkl.com>
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Problem as follows:
I have a PDP-11/44, 2 DZ11s, a (currently nonfunctional) Emulex TC12
tape controller, a Pertec-type drive for that (known working), and a
Viking UDT MSCP <> SCSI disk controller. Problem is, the Viking doesn't
raise the RACMDI bit upon completion of a command because interrupts are
off, so the boot loops forever. I tried taking out the test for RACMDI
and just putting in delay loops, but that doesn't work. (The boot hangs
later on trying to reset the controller. I dunno if the I/O went or not.)
The controller and system are known good. I can put RT-11 back on the disk
and it will run fine (excepting the date). I have a 200 meg SCSI-1 drive
on there, it will get a 540 meg drive later.
Anyway, I need to change the boot. I was told others had this problem too.
I lack MSCP docs and don't really have the knowledge to do this. Can someone
help me, or at least point me at someone who can? I'm more or less stuck for
now.
-------
So far as I know (from conversations with insiders in the past), no system
was ever shipped out of Bell Labs with Ken's self-healing trojan horse in
login and the C compiler. (For those who don't remember, both programs
were involved: login buggered so that a secret string was always accepted
as a valid password for any login; the compiler buggered to recognize when
compiling login or itself, and reinsert the buggery. Hence one can remove
the buggered sources, but as long as the binaries remain, so will the bugs.)
Ken's Turing Award lecture doesn't say whether those programs were ever
shipped to the public. He probably left it dangling on purpose, since
the point he is trying to make is that it isn't just code you have to trust,
but the programmer who wrote it; you cannot possibly know everything that's
going on inside unless you created everything involved, including compilers
and assemblers and the operating system.
Dennis's Turing Award lecture in the same issue of CACM is worth re-reading too,
especially for those who think that Open Source is a cure for the common
cold or that it was invented in the 1990s or 1980s.
Norman Wilson
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id UAA48359
for pups-liszt; Thu, 6 Jan 2000 20:45:36 +1100 (EST)
>From Warren Toomey <wkt(a)cs.adfa.edu.au> Thu Jan 6 19:45:17 2000
Received: from henry.cs.adfa.edu.au (henry.cs.adfa.edu.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id UAA48355
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 6 Jan 2000 20:45:17 +1100 (EST)
Received: (from wkt@localhost)
by henry.cs.adfa.edu.au (8.9.2/8.9.3) id UAA35060
for pups(a)minnie.cs.adfa.edu.au; Thu, 6 Jan 2000 20:45:17 +1100 (EST)
From: Warren Toomey <wkt(a)cs.adfa.edu.au>
Message-Id: <200001060945.UAA35060(a)henry.cs.adfa.edu.au>
Subject: Re: CVS Repository for UNIX
In-Reply-To: <200001060909.UAA48145(a)minnie.cs.adfa.edu.au> from "norman(a)nose.cita.utoronto.ca" at "Jan 6, 2000 4: 8:52 am"
To: pups(a)minnie.cs.adfa.edu.au (Unix Heritage Society)
Date: Thu, 6 Jan 2000 20:45:17 +1100 (EST)
Reply-To: wkt(a)cs.adfa.edu.au
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
In article by norman(a)nose.cita.utoronto.ca:
> I would argue strongly that the archive should contain absolutely pure
> copies of any historic objects, whether they were proper distributions
> or just snapshots like most of the older boot images. It's important
> to preserve accurate, unbowdlerized history; that is part of what we
> should be doing.
I agree completely.
> Even using a CVS repository somehow doesn't feel kosher to me, though
> that is probably silly as long as it is possible (and clear how) to
> extract the unimproved original, and as long as the very original
> distribution or dump tape or whatnot is kept around too so that future
> archaeologists have the right thing to study.
With CVS you can tag releases, and so you can extract back from a known
release. You can have branches at various points too, and also merge
branches. However, it really needs a CVS guru to make it work properly.
And, of course, when we get to BSD, we should bring the existing
SCCS deltas into the CVS tree, too.
The CVS idea can be someone else's project :-)
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id AAA49218
for pups-liszt; Fri, 7 Jan 2000 00:17:14 +1100 (EST)
>From Tim Shoppa <SHOPPA(a)trailing-edge.com> Thu Jan 6 23:16:41 2000
Received: from timaxp.trailing-edge.com (timaxp.trailing-edge.com [63.73.218.130])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id AAA49214
for <PUPS(a)MINNIE.CS.ADFA.EDU.AU>; Fri, 7 Jan 2000 00:16:54 +1100 (EST)
Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.ADFA.EDU.AU;
Thu, 6 Jan 2000 8:16:41 -0500
Date: Thu, 6 Jan 2000 8:16:41 -0500
From: Tim Shoppa <SHOPPA(a)trailing-edge.com>
To: PUPS(a)minnie.cs.adfa.edu.au
Message-Id: <000106081641.202001e1(a)trailing-edge.com>
Subject: Re: Viral Unix Compiler
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
>So far as I know (from conversations with insiders in the past), no system
>was ever shipped out of Bell Labs with Ken's self-healing trojan horse in
>login and the C compiler. (For those who don't remember, both programs
>were involved: login buggered so that a secret string was always accepted
>as a valid password for any login; the compiler buggered to recognize when
>compiling login or itself, and reinsert the buggery. Hence one can remove
>the buggered sources, but as long as the binaries remain, so will the bugs.)
>
>Ken's Turing Award lecture doesn't say whether those programs were ever
>shipped to the public. He probably left it dangling on purpose, since
>the point he is trying to make is that it isn't just code you have to trust,
>but the programmer who wrote it; you cannot possibly know everything that's
>going on inside unless you created everything involved, including compilers
>and assemblers and the operating system.
Perhaps Ken went even further and distributed buggered binaries of 'od'
as well (along with a 'cc' patch to re-insert the 'od' hole),
so those attempting to hand disassemble the code to *check* for
the existence of the security hole wouldn't find it.
The 'cc+login' hole is nice, sweet, and self-consistent. Attempting
to patch all the other tools to make it impossible to find these holes
sounds incredibly more complicated. Maybe it was just the way Ken
so clearly presented the "how to" lesson that makes anything I try to add
onto it sound incredibly awkward.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id BAA49497
for pups-liszt; Fri, 7 Jan 2000 01:25:03 +1100 (EST)
>From John Foust <jfoust(a)threedee.com> Fri Jan 7 00:23:43 2000
Received: from threedee.com (mail.threedee.com [209.83.65.10])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id BAA49487
for <PUPS(a)minnie.cs.adfa.edu.au>; Fri, 7 Jan 2000 01:24:42 +1100 (EST)
Received: from winnie (winnie [192.198.5.13]) by threedee.com (8.7.5/8.7.3) with SMTP id IAA27249 for <PUPS(a)minnie.cs.adfa.edu.au>; Thu, 6 Jan 2000 08:24:27 -0600
Message-Id: <3.0.5.32.20000106082343.01638ec0@pc>
X-Sender: jfoust@pc
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 06 Jan 2000 08:23:43 -0600
To: PUPS(a)minnie.cs.adfa.edu.au
From: John Foust <jfoust(a)threedee.com>
Subject: Re: Viral Unix Compiler
In-Reply-To: <000106081641.202001e1(a)trailing-edge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Has it ever been independently established that this viral
version of the compiler ever actually existed, or was this
just a parable about viral code?
- John
Tim Shoppa:
This brings up a question: should fixes (and I mean fundamental fixes
like Y2K ones) be incorporated back into the boot images in the archive, or
should they be left in their "pristine" state? (Yes, i know, some of
those boot images aren't quite so pristine.)
I would argue strongly that the archive should contain absolutely pure
copies of any historic objects, whether they were proper distributions
or just snapshots like most of the older boot images. It's important
to preserve accurate, unbowdlerized history; that is part of what we
should be doing.
There's nothing wrong with keeping fixed-up versions too, but but they
should be clearly distinguished from the historic originals. (Perhaps
we could label them `ancient' and `primary platform'?)
Even using a CVS repository somehow doesn't feel kosher to me, though
that is probably silly as long as it is possible (and clear how) to
extract the unimproved original, and as long as the very original
distribution or dump tape or whatnot is kept around too so that future
archaeologists have the right thing to study.
Norman Wilson
684 Crawford Street, Toronto
(Formerly 696 Crawford Street before a renumbering in the 1950s;
I keep thinking of putting the old number up too.)
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id UAA48301
for pups-liszt; Thu, 6 Jan 2000 20:35:35 +1100 (EST)
In article by Tim Shoppa:
> This brings up a question: should fixes (and I mean fundamental fixes
> like Y2K ones) be incorporated back into the boot images in the archive, or
> should they be left in their "pristine" state? (Yes, i know, some of
> those boot images aren't quite so pristine.)
I'd agree to both. Mind you, once you start patching, where do you stop?
We could bring V6 up to being POSIX compatible with an ANSI C compiler :-)
Seriously, at one stage I did think of trying to check-in every version of
UNIX we have into a single CVS repository. Problem is, files have moved
around, and I want to leave gaps just in case we ever get the missing versions.
> As long as we're on the topic, which versions of Unix had the C
> compiler recognize when it was recompiling [/bin/login] and put a back
> door in for the developers?
I might ask Dennis for the details. From memory, the binaries never got out
of the Labs, and it would have been around the time of V6. Also from memory,
this was the topic of Ken's speech when he won the Turing award. I wonder if
the article is lying around somewhere.
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id HAA41128
for pups-liszt; Thu, 6 Jan 2000 07:45:45 +1100 (EST)
>From Andru Luvisi <luvisi(a)andru.sonoma.edu> Thu Jan 6 07:01:27 2000
Received: from andru.sonoma.edu (andru.sonoma.edu [130.157.3.226])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id HAA41124
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 6 Jan 2000 07:45:21 +1100 (EST)
Received: (qmail 8022 invoked by uid 501); 5 Jan 2000 21:01:27 -0000
Received: from localhost (sendmail-bs(a)127.0.0.1)
by localhost with SMTP; 5 Jan 2000 21:01:27 -0000
Date: Wed, 5 Jan 2000 13:01:27 -0800 (PST)
From: Andru Luvisi <luvisi(a)andru.sonoma.edu>
To: Warren Toomey <wkt(a)cs.adfa.edu.au>
cc: Unix Heritage Society <pups(a)minnie.cs.adfa.edu.au>
Subject: Re: Viral Unix Compiler
In-Reply-To: <200001052035.HAA24359(a)henry.cs.adfa.edu.au>
Message-ID: <Pine.LNX.4.03.10001051300300.7685-100000(a)andru.sonoma.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Thu, 6 Jan 2000, Warren Toomey wrote:
[snip]
> I might ask Dennis for the details. From memory, the binaries never got out
> of the Labs, and it would have been around the time of V6. Also from memory,
> this was the topic of Ken's speech when he won the Turing award. I wonder if
> the article is lying around somewhere.
http://www.acm.org/classics/sep95/
Andru
--
--------------------------------------------------------------------------
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| luvisi(a)andru.sonoma.edu | Textile imports from Provence, France |
--------------------------------------------------------------------------
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id IAA41348
for pups-liszt; Thu, 6 Jan 2000 08:14:17 +1100 (EST)
>From "J. Capp" <jcapp(a)wilkes.kp.net> Thu Jan 6 07:33:48 2000
Received: from wilkes.kp.net (wilkes.kp.net [207.44.21.1])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id IAA41344
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 6 Jan 2000 08:13:52 +1100 (EST)
Received: from localhost (jcapp@localhost)
by wilkes.kp.net (8.9.3/8.9.3) with ESMTP id QAA11665;
Wed, 5 Jan 2000 16:33:48 -0500
Date: Wed, 5 Jan 2000 16:33:48 -0500 (EST)
From: "J. Capp" <jcapp(a)wilkes.kp.net>
To: Warren Toomey <wkt(a)cs.adfa.edu.au>
cc: Unix Heritage Society <pups(a)minnie.cs.adfa.edu.au>
Subject: Re: Viral Unix Compiler
In-Reply-To: <200001052035.HAA24359(a)henry.cs.adfa.edu.au>
Message-ID: <Pine.LNX.4.05.10001051618210.10423-100000(a)wilkes.kp.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Thu, 6 Jan 2000, Warren Toomey wrote:
>
> I might ask Dennis for the details. From memory, the binaries never got out
> of the Labs, and it would have been around the time of V6. Also from memory,
> this was the topic of Ken's speech when he won the Turing award. I wonder if
> the article is lying around somewhere.
>
Ken's speech "Reflections on Trusting Trust", was published in the
Communication of the ACM, Vol. 27, No. 8, August 1984. It describes this
"trojan horse" in great detail. But I do believe from this article that
it was an example of what could be done, not necessarily something that
was ever released into the hands of the public.
Jim Capp
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id UAA48149
for pups-liszt; Thu, 6 Jan 2000 20:09:45 +1100 (EST)
Michael Sokolov grumbled:
> Warren's note reminds me of a few other Y2K bugs I've spotted that affect
> ancient UNIX:
^^^^^^^
Would you please avoid that term? It is offensive to those for whom Kernighan/
Ritchie/Thompson/Berkeley UNIX is the primary and sole computing platform.
Thank you.
If the shoe doesn't fit, feel free not to wear it. I certainly didn't have
`Kernighan/Ritchie/Thompson/Berkeley UNIX' in mind; I rarely do, as I am
much more interested in ancient systems.
Chuckling all the way to the rest home,
Norman Wilson
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id UAA37886
for pups-liszt; Wed, 5 Jan 2000 20:13:04 +1100 (EST)
>From Greg Lehey <grog(a)lemis.com> Wed Jan 5 19:33:12 2000
Received: from freebie.lemis.com (root(a)freebie.lemis.com [192.109.197.137])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id UAA37882
for <pups(a)minnie.cs.adfa.edu.au>; Wed, 5 Jan 2000 20:12:42 +1100 (EST)
Received: (from grog@localhost)
by freebie.lemis.com (8.9.3/8.9.0) id UAA60952;
Wed, 5 Jan 2000 20:03:12 +1030 (CST)
Date: Wed, 5 Jan 2000 20:03:12 +1030
From: Greg Lehey <grog(a)lemis.com>
To: norman(a)nose.cita.utoronto.ca
Cc: pups(a)minnie.cs.adfa.edu.au
Subject: Re: 200(0) Ancient UNIX Licenses
Message-ID: <20000105200311.Y30038(a)freebie.lemis.com>
References: <200001041145.WAA32766(a)minnie.cs.adfa.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <200001041145.WAA32766(a)minnie.cs.adfa.edu.au>
WWW-Home-Page: http://www.lemis.com/~grog
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Tuesday, 4 January 2000 at 7:08:51 -0500, norman(a)nose.cita.utoronto.ca wrote:
> Warren's note reminds me of a few other Y2K bugs I've spotted that affect
> ancient UNIX:
> - date: no way to set the date past 1999 unless in the present year,
> because two-digit input.
I didn't have any problem with 2.11BSD. I just supplied 00 for the
year. Which release were you using?
Greg
--
Finger grog(a)lemis.com for PGP public key
See complete headers for address and phone numbers
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id AAA38658
for pups-liszt; Thu, 6 Jan 2000 00:03:32 +1100 (EST)
>From Tim Shoppa <SHOPPA(a)trailing-edge.com> Wed Jan 5 23:23:18 2000
Received: from timaxp.trailing-edge.com (timaxp.trailing-edge.com [63.73.218.130])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id AAA38654
for <PUPS(a)MINNIE.CS.ADFA.EDU.AU>; Thu, 6 Jan 2000 00:03:11 +1100 (EST)
Received: by timaxp.trailing-edge.com; Wed, 5 Jan 2000 8:23:18 -0500
Date: Wed, 5 Jan 2000 8:23:18 -0500
From: Tim Shoppa <SHOPPA(a)trailing-edge.com>
To: grog(a)lemis.com
CC: PUPS(a)minnie.cs.adfa.edu.au
Message-Id: <000105082318.202000b0(a)trailing-edge.com>
Subject: Re: 200(0) Ancient UNIX Licenses
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Greg wrote:
>On Tuesday, 4 January 2000 at 7:08:51 -0500, norman(a)nose.cita.utoronto.ca wrote:
>> Warren's note reminds me of a few other Y2K bugs I've spotted that affect
>> ancient UNIX:
>> - date: no way to set the date past 1999 unless in the present year,
>> because two-digit input.
>I didn't have any problem with 2.11BSD. I just supplied 00 for the
>year. Which release were you using?
That's because I did the fix for 2.11BSD back when I was Y2K-ing all
my PDP-11 sources a few years ago, and Steven incorporated it into the
distribution. The fix was quick and dirty, but works fine because
Unix effectively has an expiration date of 2038 when the signed 32-bit time
word goes negative, so it's easy enough to window the centuries.
This brings up a question: should fixes (and I mean fundamental fixes
like Y2K ones) be incorporated back into the boot images in the archive, or
should they be left in their "pristine" state? (Yes, i know, some of
those boot images aren't quite so pristine.)
As long as we're on the topic, which versions of Unix had the C
compiler recognize when it was recompiling the kernel and put a back
door in for the developers? And of course the C compiler recognized
when it was recompiling itself and made sure that the this recognition
code was also inserted. As I understand it, the distributed sources
never had this security hole in them, only the binaries, but of course
the binaries self-perpetuated the security hole even if you recompiled them.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id BAA39019
for pups-liszt; Thu, 6 Jan 2000 01:30:17 +1100 (EST)
>From "A. P. Garcia" <apg(a)execpc.com> Thu Jan 6 00:46:13 2000
Received: from playground.lan (qmailr(a)minbar-1-131.mdm.mke.execpc.com [169.207.136.133])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id BAA39006
for <PUPS(a)minnie.cs.adfa.edu.au>; Thu, 6 Jan 2000 01:29:49 +1100 (EST)
Received: (qmail 451 invoked by uid 1000); 5 Jan 2000 14:46:13 -0000
Date: 5 Jan 2000 14:46:13 -0000
Message-ID: <20000105144613.450.qmail(a)playground.lan>
From: "A. P. Garcia" <apg(a)execpc.com>
To: grog(a)lemis.com, SHOPPA(a)trailing-edge.com
Subject: Re: 200(0) Ancient UNIX Licenses
Cc: PUPS(a)minnie.cs.adfa.edu.au
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> This brings up a question: should fixes (and I mean fundamental fixes
> like Y2K ones) be incorporated back into the boot images in the archive, or
> should they be left in their "pristine" state? (Yes, i know, some of
> those boot images aren't quite so pristine.)
Ideally, both. Perhaps boot images with these fixes should be available,
yes, but so should the originals.
> As long as we're on the topic, which versions of Unix had the C
> compiler recognize when it was recompiling the kernel and put a back
> door in for the developers?
Good question! I don't know, but it was actually the login command...
Here's Brian Kernighan's note on troff and Y2K:
in n1.c, numtab[YR] is set to localtime()->tm_year, which is the
number of years since 1900. in 2000, this will contain 100.
the troff manual says that \n(yr contains "the last two digits of
the current year", but nowhere in the code is this set, and the
year can be set to anything. so it's really "the current year
minus 1900". the manual and the code are
inconsistent, which is always a problem.
in any case, in most installations troff and nroff are legacy
systems for which there is no source code, so changing them is
not feasible. furthermore, any change to troff is likely to
require changes in macro packages anyway, and may cause silent
errors by conflicting with current behavior or colliding with
previously unused names.
fortunately, it seems straightforward to fix the macro packages
that are the most likely sources of problem; individual macro
packages will have to be fixed by individuals. grepping for
"yr" will find most trouble spots.
typical macros packages use \n(yr in two ways. one is
ds ]W (printed \n(mo/\n(dy/\n(yr)
which assumes that the year is 2 digits and to be printed as 2
digits. presumably the first day of 2000 is to be printed as
1/1/00, so the fix here is to set register yr to 2 digits
.nr yr \n(yr%100
either once at the beginning (under the assumption that the year
isn't changed by the macro package) or each time \n(yr is going
to be used (providing locality at the price of more changes).
the other common usage is
.ds ]W \*(]m \n(dy, 19\n(yr
the easiest way to fix this is to add, at the beginning again,
.nr yr 1900+\n(yr
and change all subsequent uses from 19\n(yr to \n(yr.
any macro package that uses both of these constructions will need
a bit more care to unify things; the easiest fix is likely to be
two registers, one with the full year and one with the last two
digits.
.nr YR 1900+\n(yr \" 4-digit year
.nr yr \n(yr%100 \" last two digits
this will break code that happened to use this register name.
some macro packages (e.g., -mm) try to be clever about dates,
and include explicit tests to determine whether a user-provided
date has 2 or 4 digits, and then adjust by 1900; this is another
case that has to be fiddled by hand.
any approach that changes register yr at the beginning fails if
the year is set explicitly later on, as it might be by some of
the date macros in -ms and -mm. this still seems like the best
fix, however.
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id KAA35876
for pups-liszt; Wed, 5 Jan 2000 10:35:21 +1100 (EST)
