I am glad to announce a new version of my ikiwiki org plugin. This is a major change to the way things had worked previously, and is much faster than previous versions.

The installation procedure has changed, so please read the README.org file in the repository for information about how to install the plugin. Also, if you have installed a previous version, please remove that since it may conflict. Also be sure that you kill any daemonized versions of emacs that are running.

Background

This version of the plugin is no longer what ikiwiki calls an "external plugin". The overhead associated with XML-RPC was simply too high (at least on the emacs side of things). I tried working around it by having less communication between the compiler and the plugin, but the ikiwiki developers didn't really think it was a great idea. So I have basically scrapped the idea of the plugin being external.

The nice thing about that is that it allowed me to remove a lot of code on the emacs side. Instead of communication via XML-RPC, the new plugin can put the content to be interpreted in a file and call emacsclient directly.

Security

I note in README.org that there is a concern about security. This is because any program that calls another program with user-generated arguments should be concerned about security. As far as I can tell, the only way that something bad can happen is if someone creates a filename with an unmatched double-quote and convinces ikiwiki to accept it. Since ikiwiki doesn't accept filenames with double-quotes anyway, there really shouldn't be a problem.

However, I would recommend that this plugin not be used in situations where untrusted people can create files (such as from the CGI interface), unless you personally verify that nothing bad can happen. As always, this is free software and comes with no warranty.

Remaining todos

I would like to get rid of the potential security hole so that people could feel safe running this plugin from the CGI interface. I would also like to get rid of the hardcoded org configuration and let that be stored in the user's setup file. I have a branch that does that using the old architecture, so it should not be too difficult to port to the new architecture.

blog comments powered by Disqus