On Tue, Jun 20, 2017 at 02:43:58AM +0200, Guillaume MM wrote: > Le 19/06/2017 à 15:39, Enrico Forestieri a écrit : > > On Mon, Jun 19, 2017 at 06:39:22AM +0200, Jürgen Spitzmüller wrote: > > > > > Am Sonntag, den 18.06.2017, 19:56 +0200 schrieb Enrico Forestieri: > > > > > I think we need to provide an option to add -shell-escape only to > > > > > specific documents and only on the given machine. This prevents > > > > > sending > > > > > documents with -shell-escape (main problem of a document setting). > > > > > > > > This is contradictory. We avoid sending documents with -shell-escape > > > > but then add it to specific documents. So, it is the same thing. > > > > > > No, it isn't. I didn't propose a document property, but a per-document > > > session setting. This is a completely different thing. > > > > Sorry, it was not clear to me what you meant. Here is a patch following > > this strategy. > > > > - We never store in the document the need for -shell-escape. > > - When the user checks the toolbar button and then runs a latex backend, > > he is alerted that the backend will be allowed to run external programs. > > - At this point, he can decide to let the backend run (and be asked again > > next time), or to always allow execution with -shell-escape for this doc. > > - If the user chooses to always allow -shell-escape for the current > > document, > > the document path is stored in the session file, so that next time it is > > loaded on the current machine, the toolbar button will be automatically > > toggled and no question will be asked. > > - If the user manually toggles the toolbar button so that to disallow the > > -shell-escape option for an authorized document, the document is > > automatically removed from the list of authorized documents. > > > > This patch does not introduce a format change, because nothing is recorded > > in the document (the document status is only recorded in the session file). > > > > > If I understand correctly, this is the latest proposal for hard-wiring > the "-shell-escape" option when running the child latex processes, so I > will comment on this one. But I could write almost the same for all the > other proposals I have read so far. > > Let me summarize. > > Pygments: a python software that does some valuable processing on > certain text inputs. > > minted.sty: a LaTeX interface for Pygments. For some convenience reason, > minted.sty calls Pygments using the \write18 command. \write18 lets one > execute arbitrary commands on the console so it is disabled by default. > The -shell-escape option is necessary for using minted, it enables > \write18 but then \write18 can be used anywhere in the document. > > Enrico's patch: add the -shell-escape option when some conditions are > met, overriding the values shown to the user in the converter > preferences. The idea is that the user has the ability to "trust" a > document (roughly a different name for needauth, with small differences > in the details such as the ability to revoke the trust given, which is > an improvement compared to needauth). > > First I note that minted.sty executes an external tool contrary to the > LaTeX tradition. External tools are used all the time, but usually the > user is responsible for calling the external tools themselves before > calling LaTeX again. And the small convenience gain of doing it the > minted way is irrelevant to LyX users given that LyX is capable of > automating the process of calling Pygments. Here I tell you nothing new > about LaTeX and LyX. And in fact, there already exists an interface to > Pygments that works the LaTeX way: pygmentex.sty. (There also were > difficulties in guessing whether minted.sty will be able to find > Pygments, this is also no longer an issue if LyX is in charge of calling > Pygments.) > > Second, the design seems to be based on elaborate assumptions about the > user's usage and their behaviour. I would like to see the arguments > being are in principles of secure usability, which is a topic of > academic research with available articles and textbooks. See e.g.: > > https://dl.acm.org/citation.cfm?id=687663 > http://shop.oreilly.com/product/9780596008277.do > > At a cursory glance, the proposed mechanism violates several principles: > > * Prompting the user to give up security before anything happens. This > is equivalent to having no dialog at all the second or third time it > appears if the user depends on it, because they will only think about it > the first time if at all (think of "security exceptions" in your browser), > * Running child processes with more privileges than necessary, > * Forcing all-or-nothing choices (e.g. one needs to trust the whole > document instead of just minted), > * What is trusted can change over time. > > I am further less convinced because the relationship between usability > issues and security has already been pointed out by Helge and I would > have like to see his points being taken into account in the discussion. > > Until these needauth mechanisms (or whatever they are called) are > designed with the needs of users in mind following established > principles, their purpose will be for the developer to shift blame to > the user in case something bad happens. (For developers they also make > it safer to open random lyx files from the list and from the bug > tracker which is good.) > > Lastly, nobody seems to disagree that that encouraging users to add > -shell-escape by hand permanently is even worse. > > I do not know the differences in features between minted.sty and > pygmentex.sty nor how long it would take to design and implement an > interface to Pygments directly in LyX, but this is irrelevant next to > the security implications of relying on minted.sty. One must look at the > big picture and see that adding an authorization mechanism for arbitrary > execution of commands is absurd when its sole purpose is to call an > external tool from within LaTeX. My conclusion is that the current > support for Pygments must be set aside, and (after 2.3) another solution > devised which does not relies on minted.sty. > > Lastly, I find interesting the idea of a "secure" icon providing visual > feedback and the ability to revoke the permissions, and I believe that > it could be used to improve the current needauth mechanism.
Yes, you are right. -- Enrico
