doc/plugins/contrib/bibtex2html/discussion.mdwn

   1 # [[plugins/contrib/bibtex2html]] and [[plugins/contrib/compile]] plugins
   2
   3 *Answer to [[anarcat]] mentionning [[plugins/contrib/compile]] in the [[plugins/contrib/bibtex2html]] documentation.*
   4
   5 I do not think that the [[plugins/contrib/compile]] plugin can replace the [[plugins/contrib/bibtex2html]] plugin right now: the [[plugins/contrib/compile]] plugin compiles a document, and renders *an HTML link to* the compiled document, whereas (if I am not wrong), the [[plugins/contrib/bibtex2html]] plugin compiles a document, and renders *the content of* the compiled document (which happens to be some HTML code).
   6
   7 Right now, it is not possible for the [[plugins/contrib/compile]] plugin to render the *content* of the compiled document. This could be done by providing a `DESTCONTENT` template variable, containing the content of the compiled document. This should not be hard to implement.
   8
   9 -- [[Louis|spalax]] (author of [[plugins/contrib/compile]])
  10
  11 > Interesting! I am thinking of writing a simpler plugin (maybe called "exec") that would be a merge of the two approaches. There would be an `htmlize` hook to render arbitrary page extensions (based on the configuration) into anything with predefined pipelines. Then a `preprocess` hook would allo directives to inject links to documents or simply inline them like bibtex2html does. The plugin could be secure insofar as the pipelines configured are secure as well. Should that be merged in compile or be a separate plugin? --[[anarcat]]
  12
  13 >> This "arbitrary executable" stuff scares me, and I'm not going to merge anything
  14 >> like that without a relatively paranoid review. As a result, it could take a while.
  15 >>
  16 >> At some point when I have more time and energy I should try to write down what
  17 >> ikiwiki's security model is. The short version is that the plugins shipped
  18 >> with ikiwiki should never let wiki editors execute arbitrary code, even if they
  19 >> have direct VCS access or can alter "safe"-flagged setup options. The ability to
  20 >> alter non-"safe" setup options is equivalent to access to the uid running the
  21 >> wiki, and so is the ability to alter the plugins that the wiki uses.
  22 >>
  23 >> Defining pipelines or compilation commands in the setup file does not
  24 >> *directly* contradict that, because the setup option would not be flagged
  25 >> as safe, but it does provide an easy way to cause a huge
  26 >> increase in attack surface, particularly when shell scripts are known to
  27 >> be a difficult thing to write securely. If people want arbitrary compilation,
  28 >> Perl or XML-RPC (e.g. Python) plugins are probably safer (even if they call
  29 >> external commands with `IPC::Run` or `subprocess`!), and they would mean that
  30 >> the authors of the arbitrary-compilation code can't have any illusions about
  31 >> "oh, this isn't all that security-sensitive, I'm just writing an
  32 >> ad-hoc command".
  33 >>
  34 >> I hope that ImageTragick is still fresh in everyone's minds - many of the
  35 >> individual vulnerabilities there involved ImageMagick and GraphicsMagick
  36 >> running arbitrary shell pipelines from delegates.xml that turned out not
  37 >> to be hardened against invocation by a hostile user. --[[smcv]]