[TUHS] The size of EMACS, and what hides in kLOCs

[TUHS] The size of EMACS, and what hides in kLOCs

[Mutiny]

> On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa):>> I was never happy with the size of EMACS, and it had nothing to do with >> the amount of memory resources used. That big a binary implies a very >> large amount of source, and the more lines of code, the more places for >>bugs...GNU Emacs 26.0.50, GTK+ Version 3.22.8) of 2017-02-25 (Fedora25, Kernel: 4.9.11:Virtual: 794.6Resident:  36.8 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/360cae85/attachment-0001.html>

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Dave Horsfall]

On Sat, 25 Feb 2017, Larry McVoy wrote:

> Back in the days of 4MB SPARC machines (and 68K machines) we joked that 
> EMACS stood for Eight Megs And Constantly Swapping.  David Rosenthal, a 
> Sun DE, was known for running emacs on the bitmapped console in terminal 
> mode so as to not let X11 or NeWS eat up ram.

Another acronym is Esc Meta Alt Ctl Shift...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Noel Chiappa]

    > From: Dave Horsfall

    > Another acronym is Esc Meta Alt Ctl Shift...

Good one!

And there was a pretty funny fake Exxx error code - I think it was
"EMACS - Editor too big"?


I was never happy with the size of EMACS, and it had nothing to do with the
amount of memory resources used. That big a binary implies a very large amount
of source, and the more lines of code, the more places for bugs... And it
makes it harder to understand, for someone working on it (to make a
change/improvement).

        Noel

[TUHS] The size of EMACS, and what hides in kLOCs

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
> I was never happy with the size of EMACS, and it had nothing to do with the
> amount of memory resources used. That big a binary implies a very large amount
> of source, and the more lines of code, the more places for bugs...

But remember; without Emacs, we might never have had _The Cuckoo's
Egg_. Imagine the terror of that loss.

Or not. (Though Stoll's book was one of the things that more or less
introduced me to the idea of operating systems other than DOS/Windows.
I don't remember how many times I borrowed that book from the local
library, but it was probably in the double digits at least. Later I
got my own copy, which I still have.)

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] The size of EMACS, and what hides in kLOCs

[Nemo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On 26 February 2017 at 07:46, Michael Kjörling <michael at kjorling.se> wrote:
> On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
>> I was never happy with the size of EMACS, and it had nothing to do with the
>> amount of memory resources used. That big a binary implies a very large amount
>> of source, and the more lines of code, the more places for bugs...
>
> But remember; without Emacs, we might never have had _The Cuckoo's
> Egg_. Imagine the terror of that loss.

Hhhmmm.... I must dig my copy out of storage because I do not remember
emacs in there.

As for emac uses, my wife was on (non-CS) staff at a local college
affiliated with U of T.  At the time, DOS boxes sat on staff desks and
email was via a telnet connection to an SGI box somewhere on campus.
A BATch file connected and ran pine but shelled out to an external
editor.  What was the editor?  Well, I saw her composing a message
once and ending the editor session by ^X^C.

N.

[TUHS] The size of EMACS, and what hides in kLOCs

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On 26 Feb 2017 11:05 -0500, from cym224 at gmail.com (Nemo):
> On 26 February 2017 at 07:46, Michael Kjörling <michael at kjorling.se> wrote:
>> But remember; without Emacs, we might never have had _The Cuckoo's
>> Egg_. Imagine the terror of that loss.
> 
> Hhhmmm.... I must dig my copy out of storage because I do not remember
> emacs in there.

In the translated text that I have, the hacker relied primarily on
Emacs' mail feature to move the compromised atrun into place for
execution, in order to gain temporary root privileges. It is possible
that Stoll's original English text is more specific about which exact
feature was used; the translation does leave a little to be desired in
places where it's actually noticable even without having seen the
original, so I would not hold it beyond the translator (in 1991; gosh,
that's over a quarter of a century ago now) to not be completely
familiar with the finer points of Unix editors, or possibly even
wanting to simplify a little for a _readership_ that couldn't be
expected to.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] The size of EMACS, and what hides in kLOCs

[Tim Bradshaw]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

On 26 Feb 2017, at 17:05, Michael Kjörling <michael at kjorling.se> wrote:
> 
> In the translated text that I have, the hacker relied primarily on
> Emacs' mail feature to move the compromised atrun into place for
> execution, in order to gain temporary root privileges.

This was the movemail SUID bug, and it's indeed in the original although I'm not sure how much detail he goes into.

[TUHS] The size of EMACS, and what hides in kLOCs

[Jim Carpenter]

On Sun, Feb 26, 2017 at 1:23 PM, Tim Bradshaw <tfb at tfeb.org> wrote:
> This was the movemail SUID bug, and it's indeed in the original although I'm not sure how much detail he goes into.

Not much detail:

"""
    In the way it was installed on our Unix computer, the Gnu-Emacs editor
lets you forward a mail file from your own directory to anyone else in an
unusual way. It doesn't check to see who's receiving it, or even whether they
want the file. It just renames the file and changes its ownership label. You've
just transferred ownership of the file from you to me.

    No problem to sent a file from your area to mine. But you'd better not
be able to move a file into the protected systems area: only the system
manager is allowed there. Stallman's software had better make sure this can't
happen.

    Gnu didn't check. It let anyone move a file into protected systems
space. The hacker knew this; we didn't.

    The hacker used Gnu to swap his special atrun file for the system's
legitimate version. Five minutes later, the system hatched his egg, and he
held the keys to my computer.
"""

Jim

[TUHS] The size of EMACS, and what hides in kLOCs

[Nemo]

On 26 February 2017 at 12:28, Andy Kosela <andy.kosela at gmail.com> wrote:
[...]
> Are you sure it was emacs?  Most probably it was pico, which was the default
> editor for pine.  We used pine/pico for all email at our university in the
> 90's.  It was wildly popular.

Ah well, I am not sure -- that betrayed my emacs bias.  I saw ^X^C and
assumed emacs.

N.

[TUHS] The size of EMACS, and what hides in kLOCs

[Steve Nickolas]

On Sun, 26 Feb 2017, Nemo wrote:

> On 26 February 2017 at 12:28, Andy Kosela <andy.kosela at gmail.com> wrote:
> [...]
>> Are you sure it was emacs?  Most probably it was pico, which was the default
>> editor for pine.  We used pine/pico for all email at our university in the
>> 90's.  It was wildly popular.
>
> Ah well, I am not sure -- that betrayed my emacs bias.  I saw ^X^C and
> assumed emacs.
>
> N.
>

Huh.  pico's exit is just ^X, not ^X^C.

-uso.

[TUHS] The size of EMACS, and what hides in kLOCs

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

On 26 Feb 2017 20:48 -0500, from usotsuki at buric.co (Steve Nickolas):
>> On 26 February 2017 at 12:28, Andy Kosela <andy.kosela at gmail.com> wrote:
>>> Are you sure it was emacs?  Most probably it was pico, which was the default
>>> editor for pine.
>> 
>> Ah well, I am not sure -- that betrayed my emacs bias.  I saw ^X^C and
>> assumed emacs.
> 
> Huh.  pico's exit is just ^X, not ^X^C.

Yes. Pico and Nano have pretty much the same key bindings for
everything that both have (there may be some minor exception), and ^X
triggers an exit. If there are any unsaved changes, it will ask what
to do; hitting ^C at that point brings you right back to the editor.

Wikipedia puts Pine's birth at 1989, and public announcement in 1992,
so that would be reasonably believable with DOS boxen as terminals...

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] The size of EMACS, and what hides in kLOCs

[Jason Stevens]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

Emacs was the central exploit that "Jagger" used to gain root access once he got his way on a box.

It's a fantastic book, with good lessons in there that still ring true, such as keeping a log, documenting what you did and why, not emailing passwords and running a honeypot.

It also showed that if you weren't in the clique you didn't get source access and that finding even part of it was a big deal.

It's a shame his next book, silicone snake oil missed the mark by so much.

On February 27, 2017 12:05:19 AM GMT+08:00, Nemo <cym224 at gmail.com> wrote:
>On 26 February 2017 at 07:46, Michael Kjörling <michael at kjorling.se>
>wrote:
>> On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel
>Chiappa):
>>> I was never happy with the size of EMACS, and it had nothing to do
>with the
>>> amount of memory resources used. That big a binary implies a very
>large amount
>>> of source, and the more lines of code, the more places for bugs...
>>
>> But remember; without Emacs, we might never have had _The Cuckoo's
>> Egg_. Imagine the terror of that loss.
>
>Hhhmmm.... I must dig my copy out of storage because I do not remember
>emacs in there.
>
>As for emac uses, my wife was on (non-CS) staff at a local college
>affiliated with U of T.  At the time, DOS boxes sat on staff desks and
>email was via a telnet connection to an SGI box somewhere on campus.
>A BATch file connected and ran pine but shelled out to an external
>editor.  What was the editor?  Well, I saw her composing a message
>once and ending the editor session by ^X^C.
>
>N.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170227/b1b9a5e1/attachment.html>

[TUHS] The size of EMACS, and what hides in kLOCs

[Nick Downing]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8531 bytes --]

Hmmm Emacs... Editor too large :)

Well I don't use Emacs because it is the opposite of minimal, I mean
partly from a purist standpoint, partly from a practical standpoint
since we often have to do things like editing fstab before the system
is fully up. I think Joerg mentioned use of vi "for emergencies" and
that is always gonna be necessary, even for the Emacs people here. But
if I'm gonna learn something "for emergencies" I'd probably rather
just standardize on it, as I have done with vi.

That's not to say I like vi, in fact I detest it, it is clunky and
counterintuitive and modal and... I just can't stand the way it puts
the cursor "on" the current character, so that you have to use "i" to
insert before or "a" to insert after... and you can't standardize on
"i" or "a" since "i" is needed at the start of the line and "a" at the
end of the line... I can't stand the way it's line-oriented (obviously
to do with its "ex" heritage) and so you can't search on ^M (can
replace, luckily). I also have never fully bothered to learn the "vi"
command set since I felt I was kind of "camping" until I found a
better alternative, so I have improvised some truly strange sequences
to do common things like deleting a line. Haha. And recently when I
was working in the simulator with "old vi" rather than vim, I
discovered it has some really bad limitations like line length...
HOPEFULLY these are removed in "new vi", I will have to try reno in
the simulator some time.

But now to the point of my post, which is a bit of a convoluted story
that DOES touch on Emacs at the end. Well way back in the early 80s
when people believed that MSDOS would be distributed with a custom
BIOS per machine like CP/M was... and each manufacturer had their
MSDOS solution which was generally an 8086 or 8088 at around 5 MHz and
wasn't IBM compatible... various relatives of mine did their own
market research and bought interesting MSDOS machines. The most
interesting and powerful at the time was my uncle's Victor 9000 aka
Apricot ACT, it was a very futuristic machine for its time, with an
800x600 monochrome text and graphic display, variable speed floppies,
I think he had 256k or maybe 512k in it, but it could go up to about
768k or more, unlike IBM's later PC. And, with the Victor 9000 was
shipped a pretty good development system including... a text editor of
TRULY AMAZING abilities.

So the text editor was called PMATE, and it was supplied by Phoenix
Software Associates (P=Phoenix MATE=Original name of the editor before
they licensed it from its author). Yep that's Phoenix that later
became famous for BIOSes. Later on they ported PMATE to IBM XT as
well, basically they just changed the memory mapped screen to B000 or
B800 as required by IBM's MDA or CGA respectively. I used PMATE for
many years, it had an unbelievably great macro language, it had 10
buffers, you could put macros or text in each buffer, buffers could
execute each other, it could grab text into a buffer and reinsert it
somewhere else in your document, it could do search and replace with
wildcards (not regular expressions unfortunately), it could do integer
math (without operator precedence), it had various stacks and
variables and control flow and looping constructs, various disk
buffering modes and other settings.

So using PMATE I was unbelievably productive, it was great for
software development and for stuff like data entry or letter writing
too. For instance my mum was secretary of the basketball club that
myself and my brothers played for, we used to manage team lists and
mailing lists and fixtures etc, as text files in PMATE, and when we
were ready to do a mailout, we would have PMATE do a very specialized
merge of all kinds of data from different files, and then generate an
output that would be imported into WordPerfect 5.1 and laser printed.
Another time a guy was doing an election campaign and he wanted all
the electoral rolls for our district typed in (paper form was
available from public record). So I got a bunch of friends together
and we spent a week typing stuff into PMATE, after I implemented an
autocomplete facility in macros that significantly sped things up by
copying stuff from the previous line entered, etc etc. (The guy paid
us about $4000 for this, and we spent part of the money buying a
Streetfighter II arcade machine that was then communally owned by the
group which I had got together to do the data entry job, very fun
times for all :) )

Sad to say, the day came when PMATE had to be retired as I had
switched over my primary development first to Windows (where PMATE
worked but limped a bit due to its 64K limitation, despite all the
tricky disk buffering it had), and then to Linux where PMATE did not
work. I briefly tried running it under emulation. I did use the
configuration utility to patch it to generate ANSI type scape
sequences instead of using the memory mapped screen, and I even did
some CP/M to native disk access translation (I was using the Z80
version which was called ZMATE, since the 8088 port didn't offer
significant advantages in this setting). It was more or less useable,
but just too clunky for everyday use compared with vi. Anyway I deeply
mourned the loss and spent years trying to reverse engineer it, I did
at one stage make a 386 version that worked under a DOS extender, but
it would occasionally crash and I never got it debugged.

In the course of all this I was VERY VERY keen to understand more
about PMATE, finding the 8080 and Z80 versions on a little used CP/M
archive was helpful, anyway it is written by a guy called Michael
Aronsen (Arunsen?) and hence got it's name "Michael Aronsen's Text
Editor". I was thinking what a genius this guy is and wondering why he
dropped out of the scene and is no longer to be found anywhere online.
I guess it was just a college project he did because he needed an
editor, and eventually he sold it to Phoenix and washed his hands of
it. WELL strangely whenever I searched for MATE or PMATE, as well as
lots of advertisements for the Pee-Mate (a device which allows women
to pee into a bottle during lectures or long train trips etc), it
would often come up on lists of TECO implementations. I ignored this,
having no idea what TECO was, or if I briefly looked at it, then I
missed the true significance.

Well lately, there was a reference on this list to LUSERing and the
Incompatible Timesharing System (ITS), and I was idly browsing
Wikipedia etc about ITS, reading some technical documents etc, and
there was a lot of mention of Teco, this piqued my interest so I
downloaded something like Tecoc or Video Teco and compiled it and gave
it a shot... LO AND BEHOLD, PMATE IS REINCARNATED!!!!





On Mon, Feb 27, 2017 at 12:19 PM, Jason Stevens
<jsteve at superglobalmegacorp.com> wrote:
> Emacs was the central exploit that "Jagger" used to gain root access once he
> got his way on a box.
>
> It's a fantastic book, with good lessons in there that still ring true, such
> as keeping a log, documenting what you did and why, not emailing passwords
> and running a honeypot.
>
> It also showed that if you weren't in the clique you didn't get source
> access and that finding even part of it was a big deal.
>
> It's a shame his next book, silicone snake oil missed the mark by so much.
>
>
> On February 27, 2017 12:05:19 AM GMT+08:00, Nemo <cym224 at gmail.com> wrote:
>>
>> On 26 February 2017 at 07:46, Michael Kjörling <michael at kjorling.se>
>> wrote:
>>>
>>>  On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
>>>>
>>>>  I was never happy with the size of EMACS, and it had nothing to do with
>>>> the
>>>>  amount of memory resources used. That big a binary implies a very large
>>>> amount
>>>>  of source, and the more lines of code, the more places for bugs...
>>>
>>>
>>>  But remember; without Emacs, we might never have had _The Cuckoo's
>>>  Egg_. Imagine the terror of that loss.
>>
>>
>> Hhhmmm.... I must dig my copy out of storage because I do not remember
>> emacs in there.
>>
>> As for emac uses, my wife was on (non-CS) staff at a local college
>> affiliated with U of T.  At the time, DOS boxes sat on staff desks and
>> email was via a telnet connection to an SGI box somewhere on campus.
>> A BATch file connected and ran pine but shelled out to an external
>> editor.  What was the editor?  Well, I saw her composing a message
>> once and ending the editor session by ^X^C.
>>
>> N.
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.