Le 20/06/2017 à 09:54, Jürgen Spitzmüller a écrit :
2017-06-20 2:43 GMT+02:00 Guillaume MM <g...@lyx.org <mailto:g...@lyx.org>>:
...
An alternative is provided by the possibility to add
pygmentize to the list of "trusted commands", but this is something
users need to do themselves.
This is interesting. However after looking at minted.sty I am convinced
that it cannot work unfortunately because it calls many different
commands, including ones such as rm.
Note that the trust only applies to the current document as stored in
the current path, since we store absolute path names in sessions. So
trusting one document foo.lyx does not give trust to all files named
foo.lyx.
Yes this was clear enough.
The "LaTeX tradition" (up to TL 2002) was to allow all sorts of commands
via \write18. Only then, restricted shell access was introduced (which
is, of course, a good thing):
https://tex.stackexchange.com/questions/76105/what-does-restricted-write18-enabled-mean-and-why-does-texlive-keep-reporting
Just to set the records straight.
Ok. In addition, there are many external tool processing some input into
some LaTeX-readable output and this is the first time the question of
implementing -shell-escape in LyX for such a tool arises.
I cannot comment on the quality of pygmentex vs. minted, but here's an
opinion on that:
https://tex.stackexchange.com/questions/102596/minted-vs-texments-vs-verbments
While I believe that the question of providing the package most popular
at a certain point in time vs. a good enough implementation is secondary
to security implications, I also inquired at
<https://github.com/gpoore/minted/issues/166> whether it would be hard
to implement 3-step compilation in minted.sty.
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),
I am not convinced by this argument.
* Running child processes with more privileges than necessary,
If we do not grant shell-escape, we run with less privileges than necessary.
I agree that the issue is rather for users who need Pygments and are
thereby forced to grant -shell-escape.
* Forcing all-or-nothing choices (e.g. one needs to trust the whole
document instead of just minted),
I would rather trust a document (I have written myself) than a program
(I haven't).
But you would be trusting both.
* What is trusted can change over time.
Sure.
...
But the point is that we currently encourage users to enable an
unsure option _globally_ just for the sake of on document that needs
a specific feature.
Apart from the new minted.sty implementation, where else does LyX
encourages to enable an unsafe option globally?
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.
As the discussion currently stands, this (removing minted support for
the time being) will probably be the only option. With the result,
though, that users who need it will have to use ERT and extensively care
about whether to enable or disable the -shell-escape flag or nor. Which
brings us to the original problem that we look away and let users run
into trouble.
I now prefer to distinguish the two issues.
The case of the current Pygments implementation in LyX is specific since
there is no useful reason that implementing Pygments should require
-shell-escape. A decision to support a particular package is forever,
therefore the good choice has to be made from the start. Implementing it
while avoiding the security hazards of minted.sty would be a real
service made to the user.
The lack of a safe interface to -shell-escape for cases where this is
needed seems an old issue, and cannot be done in a hurry. In addition,
from Scott's original post I get that third-parties currently
encouraging the addition of -shell-escape could now explain how to make
it use needauth, or am I missing something? In that case the situation
is already improved in 2.3.
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.
I disagree. I think that this toolbar button even more promotes the
option to enable a potentially risky feature.
I am not sure what you mean, but to be clear, adding visual feedback
and the ability to revoke permissions solves some of needauth's
shortcomings, and I do not really care about the particular form it
would take.
