[9fans] dvips(1): RFC

[9fans] dvips(1): RFC

[tlaronde]

Hello,

I have started cleaning things for dvips(1) (to be included in kerTeX)
and I'd like to have feedback about people's usage of it.

Since my favorite engineering tool is called /dev/null, I have started
with the following principles:

- There was support for emtex and tpic, and a search on the Web seems to
indicate that these are obsolete: removed. Are some of you still using
these things?

- As for TeX/METAFONT, I aim for pure C89 and will remove any system
dependant stuff. For example, dvips(1) has not to deal with a spool
system etc. : it creates a file. So now, since it can't act purely as a
filter (input must be seekable), output is sent to stdout and users
redirect this wherever they want.

- There was support for embedded commands calling system(3). Either you
know what you are doing, and you can preprocess or postprocess the
files. Or you don't know what "you" are doing, because it is an alien
file and you don't know exactly what is in. Same treatment: I have
removed support for embedded system commands.

- dvips(1) is configurable by several different ways. So many that
I've discovered them working on it. I want dvips(1) to only have
one configuration file, called: "dvips.cnf" (and not "config.ps"
since it's not Postscript instructions), the file being searched,
like for TeX/METAFONT, by a PATH env variable, meaning adjusting
the path you can control what file is found first.

- under Plan9, you know what is the character encoding. This is not true
on other systems. Are there still ebcdic computers on run that may use
dvips(1) ?

Cheers,
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] dvips(1): RFC

[Richard Miller]

> - There was support for embedded commands calling system(3).

That's pretty scary.

Coincidentally, a few hours ago I was reading an article in the latest
;login entitled "Don't Take LaTeX Files from Strangers" which shows
how TeX's built-in file i/o macros can be exploited to do some not very
nice things.

The article also mentions some attacks on previewers, but the authors
seem to have missed the potential exploits enabled by this "feature"
of dvips.  A quick experiment confirms that dvips can be made to
execute aribrary shell commands by embedding them into tex source
in the right way.

>From now on I'm going to run dvips with '-R'.

Re: [9fans] dvips(1): RFC

[tlaronde]

On Fri, Aug 20, 2010 at 03:50:20PM +0100, Richard Miller wrote:
> > - There was support for embedded commands calling system(3).
>
> [...]
> The article also mentions some attacks on previewers, but the authors
> seem to have missed the potential exploits enabled by this "feature"
> of dvips.[...]

Proprietary (_bad!_) software hides the source. While some
"open" (_good!_) software shows you the hay stack... and invites you
to find the needle.

The current distributions of TeX and al. are so frightening, that it is
not surprising that the authors of the article have focused on
"features" documented and not tried to visit the Augean Stables.

And the fault is not on the original authors of the program, since the
state is unchanged in 15 or even 20 years! Only the amount of "goodies"
has increased.

In the same security audit for dvips(1), I will keep the automatic
generation of missing fonts, but the program/script called will be a
fully qualified name in the kerTeX hierarchy (supposed to be correctly
administrated), and not just a filename (last component)
called wherever such an executable with this name happen to exist in
the PATH.

The purpose of a---my claim---Unix purity that is Plan9 spirit TeX
distribution is that there is only a well identified, small amount
of added code to TeX and al. so that it can be audited, maintained
and used: no transfinite amount of hidden options.

Security will be the side-effect of maintenance and usability.

But I have been qualified by a former employer as a "psychorigid"
since I say (harshly) far more often: no! than yes, and remove more
easily than I add...  (starting by removing "great ideas" even
before starting to implement them...). So kerTeX will probably never be
very popular.
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] dvips(1): RFC

[Richard Miller]

> I want dvips(1) to only have
> one configuration file, called: "dvips.cnf" (and not "config.ps"
> since it's not Postscript instructions)

The default config file name may be silly but that's where people
who are used to dvips on another o/s will expect to find it.

Re: [9fans] dvips(1): RFC

[tlaronde]

On Fri, Aug 20, 2010 at 04:42:22PM +0100, Richard Miller wrote:
> > I want dvips(1) to only have
> > one configuration file, called: "dvips.cnf" (and not "config.ps"
> > since it's not Postscript instructions)
>
> The default config file name may be silly but that's where people
> who are used to dvips on another o/s will expect to find it.
>

If it is clearly documented, I don't think this is a problem. And since
I remove too, in the config file, the 'E' command allowing arbitrary
execution of commands via system(3), at least it will be clear that
something changed.
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] dvips(1): RFC

[ron minnich]

On Fri, Aug 20, 2010 at 9:03 AM,  <tlaronde@polynum.com> wrote:
> On Fri, Aug 20, 2010 at 04:42:22PM +0100, Richard Miller wrote:
>> > I want dvips(1) to only have
>> > one configuration file, called: "dvips.cnf" (and not "config.ps"
>> > since it's not Postscript instructions)
>>
>> The default config file name may be silly but that's where people
>> who are used to dvips on another o/s will expect to find it.
>>
>
> If it is clearly documented, I don't think this is a problem. And since
> I remove too, in the config file, the 'E' command allowing arbitrary
> execution of commands via system(3), at least it will be clear that
> something changed.


What you're doing is kind of neat, unwinding really bad ideas from TeX.

I'm amused about dvips executing commands. People have given Adobe a
lot of trouble about the embedded javascript in PDF files, and now we
see that somewhere along the line the open source community did
something even worse. When did system() creep into dvips, I wonder? I
can't imagine the original authors making such a terrible mistake.

ron

Re: [9fans] dvips(1): RFC

[tlaronde]

On Fri, Aug 20, 2010 at 10:38:17AM -0700, ron minnich wrote:
>
> I'm amused about dvips executing commands. People have given Adobe a
> lot of trouble about the embedded javascript in PDF files, and now we
> see that somewhere along the line the open source community did
> something even worse. When did system() creep into dvips, I wonder? I
> can't imagine the original authors making such a terrible mistake.

Hum... I retrieved the latest public domain version, and the file is
tagged 1990...

What may be a surprise---but not for me: I have the same experience with
GRASS---is that the advertised "community", "hundred of developers"
(even a Debian packager is called a "developer"), given 10 or 20
years, have cleaned nothing, improved nothing, but added "things"...

I have now the "Laronde's principle": intelligence is an intensive
value, not an extensive one: it doesn't sum up.

The only way to have a group of human beings acting with the maximal
intelligence is to have a group hierarchically organized with the
maximal intelligence---for the task--- at the head.

An inorganized group of human has not, as an intelligence,
the sum of the IQ, but has an IQ that is strictly less than the IQ of
the dumber of the group---because hidden in the "community", without
responsability and protected by anonymity, individuals can dare things
that they will never do if they can be identified.
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C