Re: 20030112 breaks dvips -o "|lpr"
Thanks for all the feedback guys. I had a disk fail on me (IBM Deskstar 60GB) so I lost my work machine. I'm rebuilding it now, but this set me back a day. [Stupid me, not doing backups, also lost a bunch of photos and other things I had been doing.] I will try to finish it up during the evenings; there are still some important changes coming with regards to the encoding issues pointed out earlier. After I have the changes in I will bump the version number, to 5.94. Once again, my most sincere and humble apologies for the delays. -tom
Re: 20030112 breaks dvips -o "|lpr"
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 kpathsea. Who currently is responsible for defining the default paths for dvips? Is this still in dvips, or is this in texconfig, or kpathsea? Is it simply a matter of changing those defaults, wherever they live? -tom
Re: 20030112 breaks dvips -o "|lpr"
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 files starting in the current directory and then moving on to the system directories and so on. >From a security standpoint, this is clearly bad, as you say. But I'm not sure disabling search for config files in . is, at this point, a great solution. I'm sure many people use this extensively, and we will totally break them if we make this change. For instance, what about .dvipsrc, which is *intended* as a place for the user to specify default config options for dvips, and it is searched for in $HOME, which is often the current working directory of people running dvips as well? Man, what a mess.
Re: 20030112 breaks dvips -o "|lpr"
> 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 -P foo in a configuration file due to security restrictions is disappointing. Note that dvips *does* use the current directory in most of its search paths, so anyone can drop a config.ps as part of a dvi tarball that will be picked up by dvips. (Which is another issue, since security can be disabled in the config.ps, which is why originally dvips would never let you turn security *off* in config.ps . . .) Arghhh. -tom
Re: 20030112 breaks dvips -o "|lpr"
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 . . . Gosh, there is lots of stuff that needs to be fixed in dvips; I'm very sorry for (possibly) holding up a new release. I'll make sure to spend some time this weekend on it . . . -tom
Re: finally: new teTeX pretest (20011103)
I'd be content to apply that patch (to the TeXLive tree, which is the current dvips `source' as far as I'm concerned) unless I hear any objections . . . -tom
Re: [tex-k] sourceforge for texk?
I don't think you'll have trouble getting the authors to agree if you can contact all the authors. :-( I wonder if there is a way to lock down the parts for which you do not [yet] have author permission? This is exciting, I have to admit. -tom
Re: [tex-k] sourceforge for dvipsk?
Yes yes yes! That would be great! I'd definitely encourage all of TeX Live to be on sourceforge. Sourceforge is based on cvs, is it not? I really think that's the way to go. Perforce is better than sourceforge at most things (I find), mostly having to do with keeping multi-file changes together, but using CVS is fine if we can get it out there on some public site . . . -tom
Re: [tex-k] secure mode of dvips should be default
Thanks, everyone, for taking such quick action on this. -tom
Re: [tex-k] secure mode of dvips should be default
Yeah, but people don't distribute .dvi files, do they? -tom
Re: [tex-k] secure mode of dvips should be default
Thanks for the email on dvips security! Can you explain why secure mode should be on by default? In other words, how might I run TeX and/or dvips over untrusted code? Provide me with a convincing attack scenario. A time bomb in some macro source somewhere that gets included into a distribution? Certainly if someone embeds dvips into some sort of automatic, MIME-driven viewer, yes, secure mode should be set on, but for command-line use? Thanks! -tom
Re: Xdvi: shell-command specials don't work.
I think that, it may actually be possible to support them if they fit some really simple grammar of how they are used, or else automatic conversion . . . that is, config.ps could say something like allow command jpg2eps %f - where %f means file name with no shell metacharacters or spaces or some such. But this obviously gets convoluted. What we really want is something like the standard mime content handlers. -tom
Re: Xdvi: shell-command specials don't work.
In general, it may be time to pull all those shell escapes from the dviware, including dvips . . . I haven't heard of anyone abusing them, but they are a danger. tom
