Reconsider default use of --shell-escape

[William957-web]

How can I report if I found out a vulnerability on this application?

[alexandervdm]

Assuming this is not a hypothetical, please email me directly on gummi@{the domain in my github profile}

[William957-web]

@alexandervdm
Already emailed, check your inbox~
Re: The vendor already contected me with the issue!

[mdosch]

So, what was the outcome? Is there a vulnerability?

[alexandervdm]

@alexandervdm Already emailed, check your inbox~

The phrasing of this comment could be interpreted by a reader to mean that I missed/ignored an earlier email, but just so there's no confusion I want to make it clear that our email exchange happened right after I responded here on the Github issue on Sept 19.

So, what was the outcome? Is there a vulnerability?

The issue pointed out by @William957-web refers to the fact that Gummi by default enables the "--shell-escape" flag on the LaTeX compiler command used for its live preview. This could be abused if you were to open a document from a bad actor that includes destructive or otherwise malicious commands.

This flag however is a necessity when using popular packages that run external commands like TikZ, gnuplot and many others. Like most security related design decisions, this strikes at the tension between absolute security and optimal user experience. I'm weighing some options but have not made a decision about implementing any of them and also see no need for immediate action at this time.

[William957-web]

@alexandervdm
Sorry for my inconsiderate action, I commented that just to give you a notification...
Tkx again for the detailed reply, I really like this project anyway and still using it!
P.S. Btw, can I request a CVE ID for this?

[alexandervdm]

That's quite alright, I just wanted to clarify the timeline.

I don't know the qualifications for a CVE so this is speculation, but I'd lean towards no. After all, is for example the Python interpreter vulnerable because you can open a .py file that includes a line such as os.system("rm -rf ~/")?

With regards to the issue you reported, I admit the current approach is not ideal so I'm keeping this topic open for future reference and discussion.