Make mathjax dependency optional

[terlar]

Even if the mathjax package is "optional" via devdocs-use-mathjax it is not really optional since this require call is here.

I propose making the require optional. Alternatively split out the mathjax functionality to a separate file (e.g. devdocs-mathjax).

[astoff]

I'm not necessarily against the idea, but what in your view is to be gained from making it optional?

The downside of your suggestion is clear; math rendering will not "just work" and the user will be required to discover and install one more package, and perhaps set a customization option.

(BTW, your patch doesn't actually achieve what you intended, since it keeps mathjax listed in the Package-Requires header.)

[grtcdr]

I honestly can't be bothered to go through the installation process for mathjax, it's an unnecessary package for me given that the documentation I interact with does not contain any math fragments.

I don't personally mind patching devdocs to keep the package optional but it would be nice not to require something that should not be required.

As mentioned in #44, the docstring for devdocs-use-mathjax says that the feature can be disabled whereas in reality doing so is not achievable without the changes shown in #44.

[minad]

@astoff Could you please reconsider this? Even if one uses mathjax, I have concerns to install the entire vendored dependencies in the mathjax.el package. In Debian one can install mathjax separately via apt-get. Your packages comint-mime and drepl similarly pull in mathjax - there mathjax could also be optional.

[astoff]

@minad Sorry for the delay to respond. Like I said above I have nothing in principle against making mathjax optional, but could you explain what the concern is exactly?

Is it the 2.5 MB of disk space? Is is the opacity of the vendored code (it is reproducibly built on the ELPA server, which presumably you already trust)?

[minad]

Thanks for responding.

Is is the opacity of the vendored code (it is reproducibly built on the ELPA server, which presumably you already trust)?

Yes, this is the main problem. I do not trust the vendored code and I do not want to install it. I can install Mathjax (and of course Node) via the Linux package manager. I do trust the ELPA server to some limited extent, but as far as I can tell, supply chain attacks there have not been solved yet (I've created bugs on the Emacs issue tracker related to that). But even if would trust the ELPA server fully, I would still not want to trust vendored code. I trust your code, but of course your code is not as opaque and extensive.

[astoff]

Fair enough (and at the same time I hope you agree the problem here is much smaller than sending random input to TeX, like org preview does).

Maybe you feel better with not having a copy of the vendored code in your machine, but that doesn't do anything for anyone else (or at least not anyone who wants to view math notation) and doesn't address the general problems ELPA might have. So I prefer to discuss a general solution.

Here's one idea: like I said, the build is reproducible so I could add a check against a SHA hash (say at byte-compilation time) that I would hard-code into the Elisp file. This would prove you're getting from ELPA what I intended you to get. And I'm also happy to add a check against the hash in the Github CI, so you can verify there's no funny business between ELPA and I :-).

Would that solve your concern?

I can install Mathjax (and of course Node) via the Linux package manager.

That might work, assuming MathJax is engineered with sufficient care (which is may well be, I don't know). But AFAIK much of the JS ecosystem is built with the assumption that all dependencies are "frozen" to fixed versions. So I can imagine that trying to support arbitrary MathJax versions from any Linux distro could easily lead to trouble. (Also, for the record, the 2.5 MB vendored file is boiled down from 78 MB of source files, which is substantial)

But even if would trust the ELPA server fully, I would still not want to trust vendored code.

Do you trust the binaries you get from your Linux distro? It's no different.

[minad]

Do you trust the binaries you get from your Linux distro? It's no different.

For me there is a difference. No offense to Stefan and the ELPA folks, but there are many more eyes on the Debian archives than they are on the ELPA server.

Reproducible builds and publishing the hashes certainly help. This is a general problem. I've created an Emacs bug report which goes along these lines. I wanted to have some verification, that nothing goes wrong when the package is built from the originating source and also that the commits originate from the author by checking signatures.

But then, in this case, checking hashes adds non-zero effort, which I would not have if I just install a trusted package from a trusted source. So why should I make an exception for devtools.el/mathjax.el and check the vendored code? Note that distributions like Debian also usually rip out vendored code as part of their packaging process. So even if my perspective seems paranoid, it is really not. It is a common practice to avoid vendoring in some circles. Otoh there are folks who always vendor, which may be valid under some circumstances, as in JS, because of versioning issues. But then I think I prefer the Debian way, since it feels like the leaner/safer approach by default. This means that exceptions are possible, but they need justification.

Another option would be to simply make the mathjax.el dependency optional, such that users like @grtcdr would not have to install it as long as they do not render equations. I wouldn't mind to install mathjax.el except for the vendored code.

[minad]

@astoff What do you think about downloading mathjax from a trusted source if not already available? It could be downloaded and the hardcoded hash could be checked:

https://packages.debian.org/source/bookworm/mathjax
http://deb.debian.org/debian/pool/main/m/mathjax/mathjax_2.7.9+dfsg.orig.tar.xz
d81378042cf3773fa5bd02954562e96c

The download feature should ideally be guarded by an customization option (I would still want to install mathjax via apt). Similar approaches are discussed (or even already implemented) in the context of treesitter. The treesitter grammars are not vendored but the git commits of verified grammers are pinned, and the grammars are downloaded automatically. Another option would be installation via npm but I would find that even less trustworthy than vendoring.