Re: [xwiki-devs] [curriki-devs] [Fwd: Introducing the equation rendering component and the equation macro]
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.
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(!). 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.
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.
Q: Is this setup OK as the default one? (native by default, snuggletex as fallback).
and mathtran only optional?
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? paul
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-f... ) 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/
participants (2)
-
Paul Libbrecht -
Sergiu Dumitriu