Paul Libbrecht wrote: > I hadn't seen the whole of this mail, sorry for the late reply, > > > Le 12-août-09 à 09:30, Ludovic Dubost a écrit : > >> Q: Does anybody know of any security issues with running latex, dvips or >> convert? > > you may add a warning in the readme about usage of convert, I have seen > very many "arbitrary code execution" exploits reported about image file > formats (libpng and libjpeg among others): keep your libraries and > imagemagick (convert is part of that) up-to-date.
I'm not sure this has any effect, since "convert" is invoked only with ps files generated by dvips, so I guess those are pretty safe. >> Especially with the \openin and \openout commands? > > I am not sure I know the dangers there... it should certainly be advised > to run all that as www daemon! > >> - one which uses MathTran as a remote service through HTTP requests. It >> gives results as good as the native one, enhanced with some metadata, >> and depending on the configuration of the server, it might have better >> performance than the native one. The disadvantage is that it relies >> heavily on a remote server. Note that MathTran is free software, and can >> be installed locally on the same or a neighboring server. > > MathTran is, by far, much better performing. > Moreover, the infrastructure used has proven to be able to solve the > baseline stuffs, for this, one needs the pictures to be delivered from > the same server so that the javascript reads the PNG headers(!). Indeed, I noticed that the images from MathTran are already better aligned than the native ones. But this is a future improvement. > Note that the option of TeX compilation that MathTran needs seems > shipped for everyone although J Fine said it was not. > > If you are caching, it would make the remote problem almost trivial. Yes, images are not retrieved directly from MathTran, but stored locally and served from the XWiki server. >> Oh, another minor problem is that it uses a variant of the TeX >> syntax, not LaTeX. > > that is the major issue probably. > Note that people will request very soon their own set of macros (e.g > AMStex) > >> >> - one which uses SnuggleTeX and JEuclid to transform LaTeX into MathML, >> and then render it into images. The results are not as eye-pleasing as >> those obtained from LaTeX, but it is a self-contained solution, with no >> external dependencies. >> >> SnuggleTeX uses the liberal 3-clause BSD license, JEuclid uses the >> Apache v2 license, so both can be deployed. Together, they weight in at >> 730k, so it's not a big impact. The other two implementations are not >> contaminated by the licenses of the underlying system, so there's no >> license conflict. >> >> Q: Should either one be removed? >> >> Q: Do you know of any other (better) alternative? > > I would document how to implement another one. > MathFlow of Design Science can do this (a subset called "webTeX", it is > commercial but not too expensive. If you want, you can look at the current implementations ( http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-formula/xwiki-formula-renderer/src/main/java/org/xwiki/formula/internal/ ) which are pretty small, and try to implement it. >> >> Q: Is this setup OK as the default one? (native by default, snuggletex >> as fallback). > > and mathtran only optional? Yes. It should be well documented how to switch to a different default. >> The generated images are stored in a cache (using the cache component), >> for improved performance. This new cache might increase the memory >> requirements, but fortunately it is easy to configure. > > is it not disk based? If I understood the settings correctly, it has an infinite disk-storage, and a LRU in-memory limited cache for the most recently used images (it makes sense to keep in memory the images just stored, since they will be requested right back anyway). -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
