For those (few) of us Scrivener users who compile to LaTeX, I’m wondering how many, if any, compile and then typeset their LaTeX projects using the --shell-escape setting.
I’ve been following a discussion on SE (*) where David Carlisle has been admonishing pretty much everyone NOT to use the --shell-escape setting for the security risks it poses.
As David puts it …
(the --shell-escape setting) allows a tex document that I send you, or you copy from some website to run \write18{arbitrary commands} so anything you can do on the command line could happen, All your files could be deleted, your ssh private keys could be emailed to me, or the tex file could process normally and a pdf gets made.
– David Carlisle
As a result, I’m attempting to remove all the --shell-escape settings I had in my project code, but it’s creating other issues …
Any and all thoughts from fellow LaTeX’ers would be appreciated !
All due respect to David Carlisle, but I don’t agree with this assessment. If one is going to avoid anything that can run commands as the user then I don’t know what they are doing sitting in front of a computer. That is all software, all scripts, even your Scrivener project’s processing pane has command-line access that you could use to delete all of your files if your were insane.
Should we be wary of things that we download? Absolutely, always! But most of the points of fault I see in these arguments involve other security problems, not the very notion of automation itself. For example, the notion that software may be contacting the 'net without your knowledge is the much larger problem, and one that can be solved. If you run LaTeX and suddenly get a notification about the UNIX mailer being used to connect to a mail server somewhere, then having automation in your document is no longer a “security risk”.
Funnily enough you won’t find certain major corporations pushing for that kind of security being better though. We wouldn’t want everyone to become aware of how much data is flowing out of your system and into so-called analytics companies. and so forth.
So instead we see piles of anti-user restrictions being placed around the core problems, like macOS slowly turning into a black box that you are not allowed to modify.
Is this document for your own use, or do you plan to share it?
If it’s your document, your --shell-escape command, and your machine, presumably you know what you’re doing, and even if you don’t only your own data is at risk.
(This is the fundamental philosophy of most software that pre-dates the PC era, FWIW: users know what they are doing and are responsible for their own actions.)
If you’re letting random software from the Internet run arbitrary code on your machine, well, probably you also believe that Nigerian prince’s widow really does want to share her fortune.
I’m going out on a limb here, and I cannot locate the document where I recently read it, but I believe it was a recent update from the TeX people related to the latest MacTeX2023 release that stated unequivocally that using --shell escape is NOT recommended for use in LaTeX documents.
This is ALL very much a black box to me. David’s comments, whom over the last few years I have grown to admire ( and as his web page can attest to for his many awards ) is definitely in the NO to --shell escape camp.
As someone who relies heavily on LaTeX but has a very limited understanding of the inner workings, I simply cannot ignore David’s comments. In many ways, LaTeX is a jynormous black box.
That said, the extent of when and where --shell escape is utilized in LaTeX is somewhat limited. In my case, only the minted package required that --shell escape be available when LaTeX is Typeset. Now, I am working to eliminate whatever and wherever --shell escape is applied.
As for:
anyone using the LaTeX cluster of packages is placing a certain amount of trust in the thousands of LaTeX packages. To that end, there is quite a bit of attention paid to security within the LaTeX realm. My understanding is to be included in the MacTex distribution, each package MUST be SIGNED by the developers. And LS is helpful (but not necessarily bullet-proof) at alerting when those signatures are missing or invalid.
So when David speaks on a topic that he is intimately involved with at all levels of the LaTeX system, I listen. Apologies to those who disagree.
Now, my original question is to those Scrivener users who compile their projects to LaTeX. I’d like to understand what their status, use-of and/or position is with respect to --shell escape when they Typeset their projects. Am I allowed to inquire about such a status?
shive
P.S. Re:
as with any document I prepare using Scrivener+LaTeX, there is the possibility that the document will be shared.
As a LS user, I am reminded almost every second of every day of the avalanche of data that is shared with the data collectors, every microsecond of every day!
Any person would be alarmed at what I see and experience every second that I am connected.
Hm, I’m not going to worry about it. As I do for the rest of the large ecosystem of tools I use, a malignant actor could inject themselves in any number of places, via bash / ruby / javascript / applescript / lua / TeX or bundled binaries. Malware seems to have made it into every app store, including Apple’s walled gardens. If I want to be consistent, there are so many places I should be verifying that I’d rather not use a computer at all
Backup backup backup, use cloud with a recover function, and hope for the best
So, so true … backup, backup, backup, … backup, backup, and yes … more backup.
There is NEVER enough!
That said, my concern is for those that can grab data w/o my knowing (and then keep grabbing) … but that is the price we pay for our current state of discourse within a chaotic world …
It’s not unlike the natural, non-digital world with all of the challenges it presents for organisms to stay alive …
I do appreciate your heads-up and links to the original discussion, knowledge is always valuable even if my solution does seem to consist of burying my head in the sand
Risk assessment may be one of the most private, and personal characteristics endemic to our personalities … Our assessment of risk represents a summary of all the data an individual has experienced, absorbed and processed while living in this world, so I believe respect of one’s assessment of risk is crucial to our understanding each other.
David Carlisle’s assessment of the risk presented by --shell-escape came as such a shock for something so fundamental to years of research and work that it caught me off guard, and I may have overreacted … but I suspect the swings in my response curve may swing a bit more before all is said and done.
We wouldn’t want everyone to become aware of how much data is flowing out of your system and into so-called analytics companies. and so forth.
