Ability to use a generic external HTML generator

[suhail-singh]

The RST markup converter uses the external rst2html program. However, it isn't intended for converting arbitrary markup to HTML. It has been written specifically to support the conversion of RST documents to HTML and for Hugo to leverage that capability.

It would be helpful for a user to be able to provide Hugo an arbitrary commandline invocation that generates HTML for a given document. For flexibility, the provided commandline invocation could, perhaps, have some placeholder syntax for specifying the name of the file (that is being processed by Hugo). Hugo would substitute in the name of the file into the provided invocation and then invoke the external process for generating the HTML.

With such a capability, a user would be able to, for instance, more easily customize the generated HTML using a programming language of their choice and/or reuse existing HTML generators written in other languages. For instance, having such a capability one would be able to use Emacs itself to export Org mode document to HTML (using one of several different possible Emacs Org HTML exporter packages).

[bep]

Adding a general "command line" tool is not something we're going to do (there are discussions about this).

I do, however, have plans on adding some plugin support in this area. This would be Go plugins, but from there you could do whatever you want. This would (potentially) solve some of the current issues with Pandoc, Asciidoc etc., as these new plugins would act as servers the run as long as the build runs.

[suhail-singh]

Thank you for the prompt response.

Adding a general "command line" tool is not something we're going to do

Would patches to that effect would be welcome or unwelcome?

(there are discussions about this).

Could you please provide some references to the discussions in question?

[bep]

Would patches to that effect would be welcome or unwelcome?

It would not be merged.

[suhail-singh]

Noting some information here for the benefit of others who may come across this thread.

Related issue (others are mentioned therein): https://github.com/gohugoio/hugo/issues/9351

The discussion in https://github.com/gohugoio/hugo/pull/7529 seems relevant as well. From https://github.com/gohugoio/hugo/pull/7529#issuecomment-1111384963

... I have written some prose about this here: https://gohugo.io/about/security-model/

The big problem with shelling out to pandoc and asciidoc etc. is that they from a security standpoint becomes black boxes where it not practical have any opinion on the security aspects beyond using the known features as described by the flags that we pass to it.

My main concern about this would be some phishing attacks via a malicious sites (I sometimes help people by downloading sites and building them on my computer) or modules. The pandoc config would only be available to the site config, which is a good thing.

The https://gohugo.io/about/security-model/ webpage mentions:

We shell out to some external binaries to support Asciidoctor and similar, but those binaries and their flags are predefined and disabled by default (see Security Policy). General functions to run arbitrary external OS commands have been discussed, but not implemented because of security concerns.

The security policy "restricts access to os/exec, remote communication and similar" by default, but it seems that this isn't sufficient by itself for the project's desired security guarantees (and only is sufficient in conjunction with the inability to invoke arbitrary commands).

[suhail-singh]

I do, however, have plans on adding some plugin support in this area. This would be Go plugins, but from there you could do whatever you want. This would (potentially) solve some of the current issues with Pandoc, Asciidoc etc., as these new plugins would act as servers the run as long as the build runs.

@bep could you please comment on the security aspect of the planned plugins mentioned above? I.e., how would they address or obviate your concerns as expressed in this comment?

[bep]

@suhail-singh I will in the implementing issue.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.