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.
Guillaume
