On 5 July 2017 at 06:59, Scott Kostyshak <skost...@lyx.org> wrote: > Dear all, > > This is an important topic since it involves security. I'd appreciate it > if you spent some time on understanding the issue. > > I see three options for what to do about the minted + shell-escape > issue: > > 1. Revert the recently added minted support. > > 2. Keep the current state of master. > > 3. Apply the patch at [1] (also attached for convenience). >
Hi Scott, I think you're doing an excellent job as release manager and also when summarising the issue. I therefore have to apologise that even though I have read various postings/threads on this topic, I'm still confused. Perhaps I can expand on that: - What do we lose by doing 1) above? - Is 1) necessary for users in order to use minted, or is it a convenience feature? - How many users do we think need / want to use minted, i.e. how many users are affected? Opinions seem to vary regarding what's secure and I cannot say anything to that. My general inclination is to prefer that the user to go through a bunch of manual steps in order to use dangerous features. If they remain in place, so be it. But perhaps we could warn the user when he's configured converters to use shell-escape, or if LyX was started with some global option enabling shell-escape. Perhaps by making the LyX window "look dangerous" like private browser windows, or more realistically flash a warning before each build. As an aside, I've used org-mode documents in Emacs to invoke MATLAB on snippets from within the document and it's very nice, except the really annoying part where you for each snippet have to approve that it's run. Each time. A big bug in org-mode is that it's not properly showing the snippet that's about to be executed before you approve it to be run... Perhaps I'm a masochist... Enrico argued that there are other (equally) dangerous converters already in LyX. Then that's something to address. Does it have to be for this release? If that's something to discuss, I can't say. Are many users currently exposed, i.e. likely to be using it? It's bad if we have security holes, but it's not necessarily good to immediately yank something out. On the plus side, you as the release manager can decide what's needed here as far as I am concerned. I'm sorry for not being of more help, but hopefully my comments will trigger someone else to contribute something more helpful. /Christian
