On Tue, Jun 27, 2017 at 03:33:12PM +0200, Guillaume MM wrote: > Hi Scott, > > Le 25/06/2017 à 22:41, Scott Kostyshak a écrit : > > > > Judging by the comments of gpoore, we do not want to wait for this for > > 2.3.0. But this does affect the discussion of what to do for 2.3.0, > > since we might not want to introduce a workflow in 2.3.0 that we will > > change soon after. > > I agree. > > > > > But regardless of what we decide to do about minted specifically, there > > is still the open question of what to do with other .lyx files that > > require -shell-escape. I don't think we ship any besides the newly added > > minted ones, but it might be relevant to whether we make it easy to > > temporarily add the -shell-escape or whether we want to make it hard (to > > discourage it), with the consequence that the user might forget to > > remove it. Once we answer this question in general, then we can decide > > what to do with minted. > > Looking at the problem from the -shell-escape perspective looks like a > false simplification of the problem to me and is likely to limit your > perspectives. > > It is clear that any implementation of -shell-escape will require a > compromise between security and usability, but it is not clear to me > that the compromise should be the same independently of the feature > being implemented
What I think we all agree on is that we would like to ideally allow the user to control the tradeoff between security and usability. Where I think there is disagreement is on whether we take a paternalistic approach of "are you sure you know what you're doing? Think very hard about this before you do it" or a lax approach of allowing users to shoot themselves in the foot. Should we treat LyX users like teenagers or adults? I really don't know the answer. > (I am abstract because it is not clear what else is > being discussed apart from minted.sty). Good point, it is hard to argue abstractly. We should think about other potential uses of -shell-escape from within LyX, discuss how we think each should be handled, and then try to decide on what the correct overall approach should be to handle them. > For instance, one could decide that there is no fundamental reason that > an implementation of Pygments in lyx should require -shell-escape. This > means requiring users to think about whether they want to enable > arbitrary code execution from a document for the sole purpose of having > latex instead of lyx call Pygments (which might be convenient to latex > users but pointless to lyx users). The user, given the opportunity to > think about it, will conclude that it is absurd to have to compromise > security (at least I do). > > > If the answer to the general question is "yes, let's make it easy so > > that the user is not encouraged to permanently change a converter that > > they might forget about", then from what I understand, Enrico has > > proposed a patch that does that so it is straight-forward to move on: we > > can use that approach for minted for 2.3.0, and when the github issues > > is fixed, then we can transition to a safer approach (but I suppose it > > will depend on what version of minted the user has?). > > > If the answer to the general question is "no, let's make it hard so that > > the user is discouarged from adding -shell-escape without thinking about > > it", then from what I understand, we do not make any changes to the > > current state of master (i.e. we do not apply the patch proposed by > > Enrico), but we still ship minted support as it is currently > > implemented. > > I have not seen anyone suggesting to ship minted support as currently > implemented. As currently implemented in master, I agree. I was referring to applying Enrico's patch(es), which I thought appeased Jürgen's initial concerns. > > I'm sure I got something wrong in my attempt to summarize the situation > > and figure out what we must decide on, so can someone correct me and add > > more details? Please do so without adding your opinion on what we > > *should* do. I just want to know the potential options out there. > > > > > A possible course of action. For 2.3: Thank you for proposing a course of action. In order to move forward, we need to get all proposals written down so that we can all participate in making a decision. > * Revert the work on minted for now (without reintroducing the > external template). The work done so far is likely not lost and can be > reintroduced if minted is made into a 3-step process in the future. > > * Without minted.sty support in lyx, there is no need to hurry for an > implementation of -shell-escape between feature freeze and beta release. > > * Let third parties currently encouraging the manual addition of > -shell-escape do so using the needauth mechanism. This is already an > improvement. > > * Optionally improve the current needauth mechanism with various ideas > that have been explored for -shell-escape. > > > In the future: > > * Do not add new unsafe default converters in lyx until the needauth > mechanism satisfies standard guidelines referred to in the other message. > > * Encourage safe alternatives instead whenever possible. > > > Does everyone agree that the general question (of "make it easy or hard > > for user to add -shell-escape") is important and must be addressed > > before 2.3.0beta1, or did I miss something? > > > > I find that the enhancement request came in a bit late in the 2.3 > release process for such a sensitive issue, and that 2.3 already > improves the situation with the needauth mechanism. So, if we conclude > that an implementation of Pygments should not have to request > -shell-escape, then I do not agree that this question is important and > must be addressed before 2.3.0beta1 (besides, for me it is not > well-framed either). I agree that it is late in the process, and indeed that does make stronger the proposal of "let's just revert". But this issue is not the only one holding up beta1. When we make progress on the other issues, if this one is still hanging in the air and we cannot agree on what to do, then we might need to move on and revert. My opinion is that we're not there yet. > Good luck. Thanks for your logical arguments and your proposal. They are helpful. Scott
