This plugin sounds exactly like what I need! I too have sources I want to compile on the fly, such as diagrams made with Dia and perhaps API reference manuals made with Doxygen.

I'd like to use it, but -

Problem: Any user can change the command to something dangerous that deletes file and causes irreversible damage to the system. I can even happen by mistake.

Suggestion: Add an option to the setup file that forbids to override the build command in the directive, and then only the setup file can configure build commands (if you want). Another idea, an option to validate the build command, either against a regex or using an arbitrary script specified in setup file - then e.g. you can choose which commands are allowed.

What do you think?

-- fr33domlover

The problem you mention is known, and is not a problem for me, since I am the only user of the wiki. However, if we need a secure version of this command...

Imagine we have a setup option compile_unsecure.

The directive takes the following arguments

filetype: No problem.

build: Forbidden.

source: No problem.

template: No problem.

destname and files: The problem is that right now, the command is run using a shell call. Thus, a user can easily use this argument to inject malicious commands (something like [[!compile files=";rm -fr *"]] (well, this actually would not work, but you get the idea)). I do want to keep the ability to use shell commands, for the flexibility it provides, but I imagine we can:

interpret the build command depending on its type:

if it is a string, it is interpreted as a shell command;

if it is a list of strings, the first one is the command to execute, the following ones are the arguments. If I am not wrong, this should prevent command injection.

if it is a list of lists of strings, it is a list of commands to execute (execution being stopped on the first error; usefull for stuff like latex foo.tex && dvipdf foo.dvi).

the compile_unsecure would:

forbid commands to be strings (thus, forbidding shell commands, and preventing command injections);

forbid compilation using Makefile or executable present in the wiki (to prevent users from modifying those files, and executing arbitrary commands);

forbid directive argument build.

Any thoughts?

-- Louis

This plugin is unmaintained

Unfortunately, since I am no longer using Ikiwiki, this plugin is unmaintained. I had great ideas for a new version of this plugin (and started some work), but I will not finish this work. I am dumping my TODO list for this plugin (in French) for those who might be interested.

See the TODO list.

☐ Ajouter un test slideshow avec un minimum de code utilisateur
- http://slidesjs.com/
- https://stackoverflow.com/questions/12912048/how-to-maintain-aspect-ratio-using-html-img-tag
☑ Faire aussi des tests qui utilisent le YAML du setup
☐ Se déparrasser des DEST_XXX_URL.
☐ Se débarrasser des listes de config[destname].
☑ supprimer source, nosource.
☑ Voir si on supprime make
☐ Voir si la configuration ne peut pas se faire en YAML
- ☑ Non
- ☐ Utiliser du YAML.
☐ Renommer
- ☐ type = rule
- ☐ destname = dest
- ☐ filenames = src
- ☐ ??
☐ Parser correctement la configuration (fichier de setup + arguments de la directive)
☐ Traiter src comme un pagespec? Au moins comme un glob?
☐ Variables :
- Génériques :
  - pagedir: sub/page
  - tmpdir: /home/user/wiki/.ikiwiki/3840938038409
  - wikidir: /home/user/wiki
  - destdir: $config{destdir}
  - id: un identifiant unique ?
- Fichiers :
  - Variables
    - PAS DE SRC*: TOUT DANS DEST
    - destname: foo.pdf ($destbasename.$destextension)
    - destbasename: foo
    - destextension: pdf
    - desturl: http://...foo.pdf
    - destwikiname: sub/page/foo/foo.pdf ($dirname/$destname)
    - destfullname: /var/www/wiki/sub/page/foo/foo.pdf ($destdir/$destwikiname)
    - destcontent: contenu de foo.pdf
  - Variations
    - destname0, destname1: premier, deuxième fichier source
    - idem pour les autres variables
    - destnamelist: liste des fichiers sources, tels qu'accessibles depuis le répertoire temporaire (shell, pour la commande seulement)
    - destlist: liste des fichiers sources (en utilisant HTML::Template, pour les templates seulement)
☐ Traiter destname comme un glob.
- ☐ Accéder au premier destname avec DESTNAME.
- ☐ Accéder à tous les destname avec DESTNAME0, DESTNAME1, etc.
- ☐ Accéder à une liste de destname utilisable dans un <TMPL_LOOP>
☐ Supprimer les fichiers temporaires au début.
☐ Créer des dossiers temporaires en fonction du hash de SOURCEPAGE/FILES/COMMAND.
☐ Ne pas re-compiler si le répertoire existe déjà.
☐ destname ne renomme pas le fichier : il sélectionne quel fichier publier.
☐ Mais fournir des templates par défaut :
- ☐ compile_source
- ☐ compile_link (avec des var_text et var_srctext)
- ☐ compile_album (avec un var_width et var_height et un slideshow.js seulement en exemple)
- ☐ compile_raw
☐ Doc: Fournir des exemples de règles
- ☐ gimp, libreoffice, latex, album, etc.
☐ Le fichier source n'est pas copié par défaut: si on en a besoin, il faut le mentionner dans les destnames.
☐ Documentation
- ☐ Slideshow (sans compilation)
- ☐ Tous les moyens d'accéder aux fichiers (destname, destname0, destnamelist, destlist[destname], etc.)
☐ Ne pas charger compile2 si compile est activé
- ☐ Mettre une option pour forcer
☐ wikistate: stocker compilé/erreur (rien du tout = pas encore compilé)
☐ Ajouter un argument page pour faire comme si la commande était appelée depuis ladite page?
☐ Marquer compile comme obsolète
- ☐ Source
- ☐ Documentation sur ikiwiki
- ☐ Warning dans le code
- ☐ git tag compile/v0.2
☐ Prévenir que bibtex2html est obsolète

Quick and dirty replacement

For those how might be interested: I switched from Ikiwiki to another static site generator, which does not have a compile plugin. Before writing it, I used a quick and dirty solution: using a custom Makefile, I use make build to build my website, which :

compile the files (e.g. latex documents);
build the website.

It started as a quick and dirty fix, but I think I am keeping it.

It should work with Ikiwiki too.