Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to use a generic external HTML generator #12127

Closed
suhail-singh opened this issue Feb 23, 2024 · 7 comments
Closed

Ability to use a generic external HTML generator #12127

suhail-singh opened this issue Feb 23, 2024 · 7 comments

Comments

@suhail-singh
Copy link

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 bep removed the NeedsTriage label Feb 23, 2024
@bep bep added this to the v0.124.0 milestone Feb 23, 2024
@bep
Copy link
Member

bep commented Feb 23, 2024

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
Copy link
Author

suhail-singh commented Feb 23, 2024

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
Copy link
Member

bep commented Feb 23, 2024

Would patches to that effect would be welcome or unwelcome?

It would not be merged.

@suhail-singh
Copy link
Author

suhail-singh commented Feb 23, 2024

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
Copy link
Author

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
Copy link
Member

bep commented Feb 24, 2024

@suhail-singh I will in the implementing issue.

@bep bep closed this as completed Feb 24, 2024
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants