[TUHS] Cool talk on Unix and Sendmail history, by Eric Allman

[TUHS] Cool talk on Unix and Sendmail history, by Eric Allman

[Rich Morin]

Lessons Learned from Sendmail
https://www.youtube.com/watch?v=Re1MAO6jOLE

-r

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Grant Taylor via TUHS]

On 7/21/23 1:53 PM, Rich Morin wrote:
> Lessons Learned from Sendmail
> https://www.youtube.com/watch?v=Re1MAO6jOLE

Thank you for sharing that video Rich.

The credits are finishing now.

A surprising amount of Eric's talk resonated with me.  I find it 
entertaining that he and I are doing strikingly similar things with 
email, both MTA and MUA, for seemingly similar reasons.

Thank you again.



Grant. . . .

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Larry McVoy]

On Fri, Jul 21, 2023 at 05:14:57PM -0500, Grant Taylor via TUHS wrote:
> On 7/21/23 1:53???PM, Rich Morin wrote:
> >Lessons Learned from Sendmail
> >https://www.youtube.com/watch?v=Re1MAO6jOLE
> 
> Thank you for sharing that video Rich.
> 
> The credits are finishing now.
> 
> A surprising amount of Eric's talk resonated with me.  I find it
> entertaining that he and I are doing strikingly similar things with email,
> both MTA and MUA, for seemingly similar reasons.
> 
> Thank you again.

I think it was pre-COVID but I had a gathering of systems people at my
place in the Santa Cruz mountains and Kirk and Eric were there.  I ended
up talking to Eric for quite a while and what went through my mind was
"This is so pleasant, I'd hire this guy or happily work for this guy.
He gets C like I do and likes it like I do".  It really was super 
pleasant to realize I'm not the last guy who wants to use C for 
serious work.

I suspect we're dinosaurs but we're cut from the same clothe dinosaurs.

A few pics here, not up to my usual level but whatever:

http://mcvoy.com/lm/2019-bsd-bbq/
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Grant Taylor via TUHS]

On 7/21/23 5:30 PM, Larry McVoy wrote:
> It really was super pleasant to realize I'm not the last guy who 
> wants to use C for serious work.

I thought the same thing about m4.

I still like m4.

I've used m4 for more than trivial things within the last few years.

> I suspect we're dinosaurs but we're cut from the same clothe dinosaurs.

:-)



Grant. . . .

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Larry McVoy]

On Fri, Jul 21, 2023 at 05:33:11PM -0500, Grant Taylor via TUHS wrote:
> 
> On 7/21/23 5:30???PM, Larry McVoy wrote:
> >It really was super pleasant to realize I'm not the last guy who wants to
> >use C for serious work.
> 
> I thought the same thing about m4.
> 
> I still like m4.
> 
> I've used m4 for more than trivial things within the last few years.
> 
> >I suspect we're dinosaurs but we're cut from the same clothe dinosaurs.

I think you get good at using C, and/or m4, and at a certain point it is
easier to write good code in that than start over in a different set of
tools.

My older son is learning CS and I told him that C is a lot like a
sports car on a twisty mountain road that has no guard rails.  If
you are someone who wants to be on your phone in the car, you are
gonna have a bad time.  On the other hand, if you are an expert 
driver, it's a lot of fun.

Kids these days, all they want is guard rails :)

--lm

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Steve Nickolas]

On Fri, 21 Jul 2023, Larry McVoy wrote:

> I think it was pre-COVID but I had a gathering of systems people at my
> place in the Santa Cruz mountains and Kirk and Eric were there.  I ended
> up talking to Eric for quite a while and what went through my mind was
> "This is so pleasant, I'd hire this guy or happily work for this guy.
> He gets C like I do and likes it like I do".  It really was super
> pleasant to realize I'm not the last guy who wants to use C for
> serious work.
>
> I suspect we're dinosaurs but we're cut from the same clothe dinosaurs.
>
> A few pics here, not up to my usual level but whatever:
>
> http://mcvoy.com/lm/2019-bsd-bbq/

I feel like C is one of the only languages worth using for serious code.

Most of my code is still C.

-uso.

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

On Fri, Jul 21, 2023 at 7:39 PM Steve Nickolas <usotsuki@buric.co> wrote:


> I feel like C is one of the only languages worth using for serious code.
>

Spinach!  The only language suitable or serious code is Fortran 66, where
A+I is a compiler error.

[-- Attachment #2: Type: text/html, Size: 790 bytes --]

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[segaloco via TUHS]

> A few pics here, not up to my usual level but whatever:
> 
> http://mcvoy.com/lm/2019-bsd-bbq/

Hah, that reminds me of an implementation trip I was on once.  They put our "classroom" back in an old warehouse full of all sorts of junk.  Well, one particular week they were doing a bunch of loading/unloading and there was frequently a forklift, keys and all, parked there in this large, tempting warehouse, in the dead of winter in BFE Pennsylvania.  Nothing was done that violated company policy, but then again, can't violate a company policy that doesn't exist in writing :)

Can't say I've ever gotten any projects at work to bite on C, but I've had some moderate success reducing most of our boilerplate templates into m4 macros...just in time for a lull in new work.  We've got a new project starting soon though that I'm excited to finally use it with, maybe I'll finally convert someone else at work to using some UNIX tools.

- Matt G.

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Jon Forrest]

On 7/21/2023 3:30 PM, Larry McVoy wrote:

> I think it was pre-COVID but I had a gathering of systems people at my
> place in the Santa Cruz mountains and Kirk and Eric were there.  I ended
> up talking to Eric for quite a while and what went through my mind was
> "This is so pleasant, I'd hire this guy or happily work for this guy.

I've had the pleasure and honor of working with and for Eric several
times in my career. He's one of the best programmers I've ever seen.

Jon

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Lars Brinkhoff]

Larry McVoy wrote:
> I'm not the last guy who wants to use C for serious work.

I'm using many diffent languages for many things.  But when I write
stuff that I'm humbly HOPING will be useful, say, 30 years from now, I
pick C.  It seems to me it's likely it will stick around, close to its
current form, a long time from now.  I don't think I could make that bet
on other languages that are popular now, either due to the language
itself being in flux, or its libraries, ecosystem, etc.

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Rich Salz]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

He says he wraps everything he uses in the standard library; "this tends to
make my code idiosyncratic."  At some Usenix, someone once summed it up to
me as "It is the most beautiful code that is completely unmodifiable."
Seemed appropriate.  (Compare to procmail, where the quote was "seen the
source? Gaah, my eyes are melting.")

I enjoyed watching this, thanks. I agree with the other comment "what,
nothing about security?" Sendmail did enable the first Internet worm :)

[-- Attachment #2: Type: text/html, Size: 606 bytes --]

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

On Sat, Jul 22, 2023, 8:54 AM Rich Salz <rich.salz@gmail.com> wrote:

> He says he wraps everything he uses in the standard library; "this tends
> to make my code idiosyncratic."  At some Usenix, someone once summed it up
> to me as "It is the most beautiful code that is completely unmodifiable."
> Seemed appropriate.  (Compare to procmail, where the quote was "seen the
> source? Gaah, my eyes are melting.")
>

Back in the 80s I looked at sendmail.. lots of things like strcpy written
inline. It was a mess in some ways, but ran more slowly if you cleaned all
that stuff up. It was decently well done, but had also clearly grown well
beyond its original framing...

The thing is... you don't need wrappers for standard calls. You just need
portable implementations of them for the times they are missing or broken.

I enjoyed watching this, thanks. I agree with the other comment "what,
> nothing about security?" Sendmail did enable the first Internet worm :)
>

Some of that was the times: almost nothing cared about security in a world
full of active attackers... having already forgotten the lessons of the
early v5 deployments exposing unix to lots of bored college students that
needed to do something and quickly found holes in unix's protections..
though known at the time, the stack smash wasn't believed generally to be a
severe threat. Even after the eorm, it was 10 years later openbsd started
its wide spread effort to fix them...

Gets() was the real problem that leD to the worm. The insecurity was baked
into the APIs until the 90s... and many insecure APIs weren't removed until
the last decade.

Warner

>

[-- Attachment #2: Type: text/html, Size: 2646 bytes --]

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Arrigo Triulzi via TUHS]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

On 22 Jul 2023, at 17:25, Warner Losh <imp@bsdimp.com> wrote:
> having already forgotten the lessons of the early v5 deployments exposing unix to lots of bored college students that needed to do something and quickly found holes in unix's protections.. 

As a curious young lad I was very pleased that the concept of a “secure” tty wasn’t around when I “bruteforced” my first root password over my father’s TYY.

Arrigo 

[-- Attachment #2: Type: text/html, Size: 981 bytes --]

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Dave Horsfall]

On Sat, 22 Jul 2023, Rich Salz wrote:

> (Compare to procmail, where the quote was "seen the source? Gaah, my 
> eyes are melting.")

The Procmail source is so bad that even the author has abandoned it; it's
likely to be riddled with security holes too, so you'd be nuts to use it.

> I enjoyed watching this, thanks. I agree with the other comment "what, 
> nothing about security?" Sendmail did enable the first Internet worm :)

Like C, Sendmail was not really designed with secure coding in mind.

-- Dave

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Douglas McIlroy]

"Lessons learned" overlooked the Morris worm, which exploited not only
the unpardonable gets interface, but also the unpardonable back door
that Allman built into sendmail.

This reminds me of how I agonized over Mike Lesk's refusal to remove
remote execution from uucp. (Like Eric, Mike created the feature to
help fix the myriad trouble reports these communication facilities
stimulated.) It seemed irresponsible to distribute v7 with the feature
present, yet the rest of uucp provided an almost indispensable
service. The fig leaf for allowing uucp in the distribution was that
remote execution was described in the manual. If you didn't like it
you could delete or fix uucp. (Sendmail's Trojan horse was
undocumented, though visible in the code.)

Doug

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Norman Wilson]

Doug McIlroy:

  This reminds me of how I agonized over Mike Lesk's refusal to remove
  remote execution from uucp.

====

Uux, the remote-execution mechanism I remember from uucp, had
rather better utility than the famous Sendmail back-door: it
was how uucp carried mail, by sending a file to be handed to
mailer on the remote system.  It was clearly dangerous if
the remote site accepted any command, but as shipped in V7
only a short list of remote commands was allowed: mail rmail
lpr opr fsend fget.  (As uucp was used to carry other things
like netnews, the list was later extended by individual sites,
and eventually moved to a file so reconfiguration needn't
recapitulate compilation).

Not the safest of mechanisms, but at least in V7 it had a use
other than Mike fixing your system for you.

Is there some additional history here?  e.g. was the list of
permitted commands added after arguments about safety, or
some magic command that let Mike in removed?  Or was there a
different remote-execution back door I don't remember and don't
see in a quick look at uuxqt.c?

Norman Wilson
Toronto ON

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

There was also a feature Mike Lesk added that allowed a marked line,
something like

%! command

to cause the command to be executed when the recipient read the mail, for
example to demonstrate a feature of a program or teach the recipient
something. He meant well. Dennis had the closest he ever had to a
conniption, and it was taken out post haste. Meaning well is not enough.

-rob


On Mon, Jul 31, 2023 at 4:23 AM Norman Wilson <norman@oclsc.org> wrote:

> Doug McIlroy:
>
>   This reminds me of how I agonized over Mike Lesk's refusal to remove
>   remote execution from uucp.
>
> ====
>
> Uux, the remote-execution mechanism I remember from uucp, had
> rather better utility than the famous Sendmail back-door: it
> was how uucp carried mail, by sending a file to be handed to
> mailer on the remote system.  It was clearly dangerous if
> the remote site accepted any command, but as shipped in V7
> only a short list of remote commands was allowed: mail rmail
> lpr opr fsend fget.  (As uucp was used to carry other things
> like netnews, the list was later extended by individual sites,
> and eventually moved to a file so reconfiguration needn't
> recapitulate compilation).
>
> Not the safest of mechanisms, but at least in V7 it had a use
> other than Mike fixing your system for you.
>
> Is there some additional history here?  e.g. was the list of
> permitted commands added after arguments about safety, or
> some magic command that let Mike in removed?  Or was there a
> different remote-execution back door I don't remember and don't
> see in a quick look at uuxqt.c?
>
> Norman Wilson
> Toronto ON
>

[-- Attachment #2: Type: text/html, Size: 2578 bytes --]

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[George Michaelson]

It must be the fate of all UUCP-like protocols to recapitulate the
life of UUCP. My memory is that ACSNet (quite UUCP like) had both an
execute, and a *@dom.ain and even root@* handling, and that it caused
some DOS consequences.

There's nothing implicitly wrong with remote execution, remote job
entry was a thing back in the coloured book protocols. I guess the
problem inherent in "just do this thing" in UUCP was the permissions
and runtime context. But a chroot() and permissions drop should have
made it less risky. There is the "but anyone can inject it" problem.

Execute on read is just awful. But, now we have HTML to track "they
read it" through URL fetch.

G

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Erik E. Fair]

	Date: Mon, 31 Jul 2023 09:34:56 +1000
	From: George Michaelson <ggm@algebras.org>

	[...]

	Execute on read is just awful. But, now we have HTML to track "they
	read it" through URL fetch.

And then the utterly disastrous: JavaScript. It should be *eliminated*
from the WWW as the gross security violation it is.

	"don't run software from strangers",

	Erik Fair

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On Sun, Jul 30, 2023, 5:59 PM Erik E. Fair <fair-tuhs@netbsd.org> wrote:

>
>         Date: Mon, 31 Jul 2023 09:34:56 +1000
>         From: George Michaelson <ggm@algebras.org>
>
>         [...]
>
>         Execute on read is just awful. But, now we have HTML to track "they
>         read it" through URL fetch.
>
> And then the utterly disastrous: JavaScript. It should be *eliminated*
> from the WWW as the gross security violation it is.
>
>         "don't run software from strangers",
>


Write once, run everywhere.

Warner

>         Erik Fair
>

[-- Attachment #2: Type: text/html, Size: 1293 bytes --]

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Grant Taylor via TUHS]

On 7/30/23 7:26 PM, Warner Losh wrote:
> Write once, run everywhere.

Wasn't that "Java" proper and not "JavaScript"?



Grant. . . .

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Mon, Jul 31, 2023, 4:58 PM Grant Taylor via TUHS <tuhs@tuhs.org> wrote:

> On 7/30/23 7:26 PM, Warner Losh wrote:
> > Write once, run everywhere.
>
> Wasn't that "Java" proper and not "JavaScript"?
>

It was.. but since Javascript has the name Java in it... I thought I'd make
that joke...

Warner

>
> Grant. . . .
>

[-- Attachment #2: Type: text/html, Size: 903 bytes --]

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Grant Taylor via TUHS]

On 7/31/23 6:05 PM, Warner Losh wrote:
> It was.. but since Javascript has the name Java in it... I thought I'd 
> make that joke...

Fair enough.

I thought perhaps I was misremembering things and more caught up in 
trying to correct my mental understanding and failed to see the humor.



-- 
Grant. . . .

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Niklas Karlsson]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

Den mån 31 juli 2023 kl 02:27 skrev Warner Losh <imp@bsdimp.com>:

>
>
> On Sun, Jul 30, 2023, 5:59 PM Erik E. Fair <fair-tuhs@netbsd.org> wrote:
>
>>
>>         Date: Mon, 31 Jul 2023 09:34:56 +1000
>>         From: George Michaelson <ggm@algebras.org>
>>
>>         [...]
>>
>>         Execute on read is just awful. But, now we have HTML to track
>> "they
>>         read it" through URL fetch.
>>
>> And then the utterly disastrous: JavaScript. It should be *eliminated*
>> from the WWW as the gross security violation it is.
>>
>>         "don't run software from strangers",
>>
>
>
> Write once, run everywhere.
>

I've seen some cynical people render it as "write once, run away".

Niklas

[-- Attachment #2: Type: text/html, Size: 1559 bytes --]

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Grant Taylor via TUHS]

On 7/31/23 8:51 PM, Niklas Karlsson wrote:
> I've seen some cynical people render it as "write once, run away".

I've heard:

  - Write once and crash everywhere.

  - Just another vulnerability announcement.



-- 
Grant. . . .

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Theodore Ts'o]

On Tue, Aug 01, 2023 at 03:51:28AM +0200, Niklas Karlsson wrote:
> >
> > Write once, run everywhere.
> 
> I've seen some cynical people render it as "write once, run away".

I've always preferred, "Write once, run screaming".  :-)

     	    	       	      	    	- Ted

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[segaloco via TUHS]

> And then the utterly disastrous: JavaScript. It should be eliminated
> from the WWW as the gross security violation it is.
> 
> "don't run software from strangers",
> 
> Erik Fair

The browser is becoming more and more of an OS of its own, it just needs to act like it in the security realm.

- Matt G.

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Marc Donner]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

Nathaniel (Mr Mime) Borenstein came up with something (atomicmail?) that
was intended to be more functional than raw text but safer than free
execution of unknown code.  I disremember the details.  I don’t think it
ever got traction.

On Sun, Jul 30, 2023 at 7:59 PM Erik E. Fair <fair-tuhs@netbsd.org> wrote:

>
>         Date: Mon, 31 Jul 2023 09:34:56 +1000
>         From: George Michaelson <ggm@algebras.org>
>
>         [...]
>
>         Execute on read is just awful. But, now we have HTML to track "they
>         read it" through URL fetch.
>
> And then the utterly disastrous: JavaScript. It should be *eliminated*
> from the WWW as the gross security violation it is.
>
>         "don't run software from strangers",
>
>         Erik Fair
>
-- 
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>

[-- Attachment #2: Type: text/html, Size: 1589 bytes --]

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Erik E. Fair]

	Date: Tue, 1 Aug 2023 05:22:17 -0400
	From: Marc Donner <marc.donner@gmail.com>

	Nathaniel (Mr Mime) Borenstein came up with something (atomicmail?)
	that was intended to be more functional than raw text but safer
	than free execution of unknown code. I disremember the details.
	I don't think it ever got traction.


You remember correctly. It got stomped by those of us in the IETF MIME working group with approximately the same forceful negative reaction as you've seen here to Mike Lesk's idea of instantly executed Unix commands in e-mail.

I'm hardly innocent of this - while writing & operating the AppleLink/Internet e-mail gateway at Apple in the 1990s, I discovered that I could download the entire user directory from AppleLink (over 50k users: all Apple employees, Apple 3rd-party developers, Apple retail dealers - the whole "Apple Federation" at that time was on AppleLink), which included both usernames and "full name" fields, which could provide the basis for an AppleLink directory lookup service on the Internet. I figured it'd be easy to use FINGER & WHOIS as the protocol ports since the outputs of those are basically unstructured (unspecified) ASCII text, e.g. "finger fair@applelink.apple.com" would return a list of all usernames and full names matching "fair".

I was writing in Perl because e-mail gatewaying is primarily about string handling, and it sucks to write in C for that. The best performing way to implement the text search was to use its eval() function with a regex constructed from the network protocol input. I tested it, and it worked great, but I bet you can guess where this is going - how to perfectly sanitize the search term inputs taken directly from the net so they don't become arbitrary Perl code?

I never deployed it, partly because I couldn't convince myself I'd made the service completely secure, and partly as a privacy matter: finger (especially after the 1989 Morris Worm & the increasing amounts of e-mail spam) was not a service that sites were offering any longer because there were too many bad actors on the Internet, and it just wasn't a good idea to be as open & trusting as the ARPANET had been. I lament the passing of that culture from time to time.

I think anyone with a modicum of experience in computer & systems security can instantly recognize the dangers in executable code transmitted unsolicited to unwary recipients and automatically executed without prior, explicit permission, and works to stop anything along those lines from becoming standard practice because, despite all the protestations that "it's run in a sandbox, it's safe!", the proponents can never prove their case beyond reasonable doubt.

How many bugs were discovered in the "restricted shell" (rsh) over the years?

Sometimes we fail to prevent such bad ideas from being implemented: JavaScript in HTML/HTTP is one such. What concerns me these days is how often JavaScript is showing up in text/html e-mail. At least visiting a website (URL) with a web browser is, to some degree, an act of volition. Particularly with MIME, Internet e-mail has to be parsed and presented (and which HTML parsers these days do not also include a JavaScript interpreter?), not merely spewed to a presumed-ASCII (OK, UTF-8) terminal. Even simple spew could be dangerous: who remembers "intelligent terminal" transmit-back codes and the mischief those caused?

IIRC, the question we posed to Nathaniel was: "do we really want to enable letter bombs?"

Some of us also remembered (and possibly referenced) the UNAbomber.

	Erik

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Dave Horsfall]

On Tue, 1 Aug 2023, Erik E. Fair wrote:

> Even simple spew could be dangerous: who remembers "intelligent 
> terminal" transmit-back codes and the mischief those caused?

ASCII bombs were fairly popular in the old MS-DOS BBS days (format the 
disk, anyone?), and it was possible over packet radio too (sort of a BBS 
via Amateur i.e. "ham" radio).

-- Dave (vk2kfu)

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Ron Natalie]

ASCII Bombs?   Like my Letter Bomb Transport Protocol (LBTP)?

https://groups.google.com/g/net.followup/c/OJBALbzTq4w/m/LoxMnbz0bwMJ

It seems to have lost something in the formatting (the leading spaces 
were all removed).



------ Original Message ------
From "Dave Horsfall" <dave@horsfall.org>
To "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Date 8/1/23, 8:37:20 PM
Subject [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric 
Allman

>On Tue, 1 Aug 2023, Erik E. Fair wrote:
>
>>  Even simple spew could be dangerous: who remembers "intelligent
>>  terminal" transmit-back codes and the mischief those caused?
>
>ASCII bombs were fairly popular in the old MS-DOS BBS days (format the
>disk, anyone?), and it was possible over packet radio too (sort of a BBS
>via Amateur i.e. "ham" radio).
>
>-- Dave (vk2kfu)

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Grant Taylor via TUHS]

On 8/2/23 9:52 AM, Ron Natalie wrote:
> ASCII Bombs?   Like my Letter Bomb Transport Protocol (LBTP)?
> 
> https://groups.google.com/g/net.followup/c/OJBALbzTq4w/m/LoxMnbz0bwMJ

~chuckle~

> It seems to have lost something in the formatting (the leading spaces 
> were all removed).

Ya....

People think I'm weird for not liking languages that use white space as 
structural definition.  Frequently those people have not experienced 
such a failure as what has happened to your ASCII Bomb.



Grant. . . .

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[segaloco via TUHS]

> People think I'm weird for not liking languages that use white space as
> structural definition.
>
> Grant. . . .

This is my chief gripe with Python, although on the flip side Python isn't the right language anyway for most scenarios where I use whitespace/indentation to imply structure the language itself can't articulate.  It's meant for mainly functional programming as I understand it so the structure does enforce some stylistic practices conducive to good functional programming.  Still a shame to force a particular style approach by default rather than just strongly suggest it.

What strikes me particularly odd about the Python case is that its not like that space-sensitivity evolved out of the same line of reasoning as the compulsory spacing in FORTRAN, COBOL, etc.  It seems mainly to be a way to operate without code blocks, with the "blocks" being implied by indentation rather than braces, parens, or some other delimiter.

In UNIX of course we have our own little variation on this problem with make(1) and the need to tab out the rule definition.  I seem to recall reading somewhere (perhaps Doug's McIlroy's UPM excerpts) that that Stu Feldman considered undoing that but there were already users who that would've caused trouble for, so make's early, entrenched adoption stymied attempts at the time to rectify this.  Anyone with better details feel free to correct me.

- Matt G.

P.S. This answer can be off list or spin off a separate thread for make junkies, but did any AT&T or BSD revision of make(1) support rule names coming from variables rather than explicitly entered?

For instance:

$(BIN): $(OBJS)
    $(CC) $(LDFLAGS) -o $(BIN) $(OBJS) $(LIBS)

I used to use this in makefiles but at some point, I think with one of the BSDs, it balked at the idea of a variable rule name and so it fell out of my practice in trying to avoid GNUisms.

It's been a while but I feel like I ran through and tried this on V7, System III, and PDP-11 System V and all of them were unhappy about that construct.  I can try and get on the LCMs 3B400 later to see what SVR3 does.  I don't remember which of the BSDs (if not multiple) I ran into that issue on initially, but I can't imagine one of the major streams would work that in without the other two wanting to copy their notes.

Maybe an alternative question is if folks are aware of make implementations besides GNU that *do* support that sort of thing.

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 3290 bytes --]

On Wed, Aug 2, 2023 at 4:20 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> > People think I'm weird for not liking languages that use white space as
> > structural definition.
> >
> > Grant. . . .
>
> This is my chief gripe with Python, although on the flip side Python isn't
> the right language anyway for most scenarios where I use
> whitespace/indentation to imply structure the language itself can't
> articulate.  It's meant for mainly functional programming as I understand
> it so the structure does enforce some stylistic practices conducive to good
> functional programming.  Still a shame to force a particular style approach
> by default rather than just strongly suggest it.
>
> What strikes me particularly odd about the Python case is that its not
> like that space-sensitivity evolved out of the same line of reasoning as
> the compulsory spacing in FORTRAN, COBOL, etc.  It seems mainly to be a way
> to operate without code blocks, with the "blocks" being implied by
> indentation rather than braces, parens, or some other delimiter.
>
> In UNIX of course we have our own little variation on this problem with
> make(1) and the need to tab out the rule definition.  I seem to recall
> reading somewhere (perhaps Doug's McIlroy's UPM excerpts) that that Stu
> Feldman considered undoing that but there were already users who that
> would've caused trouble for, so make's early, entrenched adoption stymied
> attempts at the time to rectify this.  Anyone with better details feel free
> to correct me.
>
> - Matt G.
>
> P.S. This answer can be off list or spin off a separate thread for make
> junkies, but did any AT&T or BSD revision of make(1) support rule names
> coming from variables rather than explicitly entered?
>
> For instance:
>
> $(BIN): $(OBJS)
>     $(CC) $(LDFLAGS) -o $(BIN) $(OBJS) $(LIBS)
>
> I used to use this in makefiles but at some point, I think with one of the
> BSDs, it balked at the idea of a variable rule name and so it fell out of
> my practice in trying to avoid GNUisms.
>

BSD has long supported

PROG=cat

.include <bsd.prog.mk>

to have it deal with all the details. Of course, FreeBSD's is more complex
than that, because nothing is ever simple.

And I think even V7 make supported what you described, as well as implicit
rules for compiling .c into a .o or into a binary.


> It's been a while but I feel like I ran through and tried this on V7,
> System III, and PDP-11 System V and all of them were unhappy about that
> construct.  I can try and get on the LCMs 3B400 later to see what SVR3
> does.  I don't remember which of the BSDs (if not multiple) I ran into that
> issue on initially, but I can't imagine one of the major streams would work
> that in without the other two wanting to copy their notes.
>

They'd likely be happier if you used {} instead of () for variable
expansion.


> Maybe an alternative question is if folks are aware of make
> implementations besides GNU that *do* support that sort of thing.
>

The NetBSD/FreeBSD pmake does, and has since before NetBSD/FreeBSD were a
thing (at least to 4.2BSD, and I think even further back since I'm nearly
positive V7 supported it, though I've not cranked up a V7 VM to chek).

Warner

[-- Attachment #2: Type: text/html, Size: 4146 bytes --]

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Rich Salz]

[-- Attachment #1: Type: text/plain, Size: 177 bytes --]

> [Python is] meant for mainly functional programming as I understand it

Not true. It has some neat functional features (list comprehensions) but
that's not really its intent.

[-- Attachment #2: Type: text/html, Size: 233 bytes --]

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Dave Horsfall]

On Wed, 2 Aug 2023, Ron Natalie wrote:

> ASCII Bombs?   Like my Letter Bomb Transport Protocol (LBTP)?

Some "smart" terminals could have their function keys programmed by escape 
characters, then subsequently invoked...

> https://groups.google.com/g/net.followup/c/OJBALbzTq4w/m/LoxMnbz0bwMJ
> 
> It seems to have lost something in the formatting (the leading spaces 
> were all removed).

Aha...  Much better with a bit of imagination :-)

Which reminds me: the reason why I refuse to use Python is that white 
space is part of the syntax; the last language I used with that property 
was FORTRAN (and I also had to learn COBOL as part of my CS degree, but 
fortunately never had to use it).

-- Dave