> "Giuseppe" == Giuseppe Ghibò <[EMAIL PROTECTED]> writes:
> Furthermore in output pipe we could have different level of
> security, so to have both tex users as well as unix sysadmin
> happy (the latter mainly because dvips is for instance used in
> some printer filter which c
> Don't see the necessity. root filters (like in line spoolers) are
> run in separate directories and with command line options specified
> by the filter programmer.
Full ACK. Whoever writes such a filter should know what he is doing and
put something like an explicit -f or -o argument into the c
> Date: Thu, 16 Jan 2003 22:39:18 +0100
> From: =?ISO-8859-1?Q?Giuseppe_Ghib=F2?= <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: 20030112 breaks dvips -o "|lpr"
>
> [and for special backtick, only allow a common set of commands at
> a fixed path, e.g. convert from ImageMagick]
For for
Giuseppe Ghibò <[EMAIL PROTECTED]> writes:
> 2) protect the system when dvips run as root as filter. The filters
> should have options to let all the pipes disabled.
Don't see the necessity. root filters (like in line spoolers) are
run in separate directories and with command line options specif
Okay, so if we agree the solution is:
1. Allow the output pipe to be opened in all cases
and
2. Never search for configuration files (config.ps, config.printer,
and .dvipsrc are the only ones critical here) in the current
directory
then I've got some questions about dvips vs kpath
Tomas G. Rokicki wrote:
> Dvips has *always* searched in the current directory first for virtually
> all files, config files, tfm files, vf files, figure files, header files,
> etc. So all the blame on that goes to me. This was intended as a
> feature; users sometimes want to override something,
Giuseppe Ghibò <[EMAIL PROTECTED]> writes:
> Furthermore in output pipe we could have different level of
> security, so to have both tex users as well as unix sysadmin happy
> (the latter mainly because dvips is for instance used in some
> printer filter which could run with root privileges):
>
>
Vladimir Volovich wrote:
> "TE" == Thomas Esser writes:
>
> TE> * explicit encoding for Knuth's 75 fonts in map files; this helps
> TE> dvipdfm
>
> that will make dvips-generated PS files a bit bigger (if the explicit
> encoding is used in dvips map file too) - so just a thought: maybe
> it's pos
Tomas G. Rokicki wrote:
>>only config files in "trusted paths" can be used for external commands etc.
>
>
> Sounds like we're getting closer to Perl's taint mode.
>
> In any case, this is the sort of thing we'd have to depend on
> kpathsea to provide, right? I don't see that happening in this
> r
David Kastrup writes:
> "Tomas G. Rokicki" <[EMAIL PROTECTED]> writes:
>> What if someone untar's a paper distribution with a dvi file and
>> associated figures, that contains a .dvipsrc file? Or config.ps
>> file?
> Configuration files should not be searched for in the current
> directory. I a
Tomas G Rokicki writes:
>> only config files in "trusted paths" can be used for external commands etc.
> Sounds like we're getting closer to Perl's taint mode.
> In any case, this is the sort of thing we'd have to depend on
> kpathsea to provide, right?
I'm taking a look at what it would take fo
Thomas Esser writes:
>> I am one of tetex maintainers of Debian and we got a bug report
>> that "please include pdftosrc in tetex-bin"
> I see. pdftosrc was even included in good-old-teTeX-1.0... I have
> just added
> @PTEX@pdftosrc = pdftosrc
> ...tie $(ttf2afm) $(pdftosrc) ...
> to texk/web2
"Tomas G. Rokicki" <[EMAIL PROTECTED]> writes:
> What if someone untar's a paper distribution with a dvi file and
> associated figures, that contains a .dvipsrc file? Or config.ps
> file?
Configuration files should not be searched for in the current
directory. I am repeating myself here.
> And
"Tomas G. Rokicki" <[EMAIL PROTECTED]> writes:
> Dvips has *always* searched in the current directory first for virtually
> all files, config files, tfm files, vf files, figure files, header files,
> etc. So all the blame on that goes to me. This was intended as a
> feature; users sometimes want
Dvips has *always* searched in the current directory first for virtually
all files, config files, tfm files, vf files, figure files, header files,
etc. So all the blame on that goes to me. This was intended as a
feature; users sometimes want to override something, much like TeX
searches for input
Thomas Esser <[EMAIL PROTECTED]> writes:
> > That's a very good point; if the *user* specifices -o "|..." that
> > *should* override the security setting.
>
> Good, we agree here.
>
> > What if the -o option comes from a config file; should that override
> > the security setting?
>
> In secure
> I am one of tetex maintainers of Debian and we got a bug report
> that "please include pdftosrc in tetex-bin"
I see. pdftosrc was even included in good-old-teTeX-1.0... I have
just added
@PTEX@pdftosrc = pdftosrc
...tie $(ttf2afm) $(pdftosrc) ...
to texk/web2c/Makefile.in. Seems that this is
> only config files in "trusted paths" can be used for external commands etc.
Sounds like we're getting closer to Perl's taint mode.
In any case, this is the sort of thing we'd have to depend on
kpathsea to provide, right? I don't see that happening in this
release. Yet, not allowing
o !lpr
On Jan 16, Thomas Esser wrote:
> > That's a very good point; if the *user* specifices -o "|..." that
> > *should* override the security setting.
>
> Good, we agree here.
>
> > What if the -o option comes from a config file; should that override
> > the security setting?
>
> In secure mode, dvip
> that will make dvips-generated PS files a bit bigger (if the explicit
> encoding is used in dvips map file too) - so just a thought: maybe
> it's possible to have sriver-sprcific source map files (from which
> driver-specific final map files are generated)? e.g. there may be a
Well, sure, such t
That's a very good point; if the *user* specifices -o "|..." that
*should* override the security setting.
What if the -o option comes from a config file; should that override
the security setting? Probably not, because the override could
come from a .dvipsrc file created by a malicious program .
> That's a very good point; if the *user* specifices -o "|..." that
> *should* override the security setting.
Good, we agree here.
> What if the -o option comes from a config file; should that override
> the security setting?
In secure mode, dvips should not trust the dvi file. I don't see why
d
[added Tomas Rokicki to the recepients, throwing him into this
discussion]
Hi,
-o "|lpr" no longer works, because the default config file of dvips now
correctly sets secure mode on. Secure mode can be turned off by putting
z0 into a config file for dvips or by specifying -R0 on the commandline
(
Dear list members, pk font generation through mktexpk under my
sun-sparc-solaris2.9 with gcc-3.2.1 system fails with error messages:
mf-nowin: fatal: putbyte(255) failed.
gftopk: fatal: putbyte(255) failed.
Is this a Solaris2.9, gcc-3.2.1, teTeX-beta or yet another error? Did
you encounter the sa
Harald Koenig <[EMAIL PROTECTED]> writes:
> Hi,
>
> using 20030112 pretest, dvips can't write output to pipes anymore:
>
> turtle fdp > dvips -Php11 Protokoll_Regelkom_021217.dvi -o '| lp -dhp11'
> This is dvips(k) 5.92a Copyright 2002 Radical Eye Software (www.radicaleye.com)
>
Atsuhito Kohda writes:
> Hi,
> I am one of tetex maintainers of Debian and we got a bug report
> that "please include pdftosrc in tetex-bin"
> It seemed only a slight modification of texk/web2c/Makefile.in
> would make pdftosrc. Is there any reason that pdftosrc was not
> made by default?
I'm
On Jan 16, Robin Fairbairns wrote:
> what os are you using?
>
> there's just been a report (on c.t.t) of this as a direct consequence
> of upgrading to rh8.0
I see this problem with SuSE 7.2 running 20030112 (teTeX was built on RedHat 6.2),
and IRIX64-6.5 running beta-20021216.
SuSE 7.3 runnin
what os are you using?
there's just been a report (on c.t.t) of this as a direct consequence
of upgrading to rh8.0
robin
Hi,
using 20030112 pretest, dvips can't write output to pipes anymore:
turtle fdp > dvips -Php11 Protokoll_Regelkom_021217.dvi -o '| lp -dhp11'
This is dvips(k) 5.92a Copyright 2002 Radical Eye Software (www.radicaleye.com)
' TeX output 2003.01.16:1546' -> | lp -dhp11
29 matches
Mail list logo
