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):
#9351

The discussion in #7529 seems relevant as
well. From #7529 (comment)

... 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]

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.