subject:"Can shell\-escape take advantage of needauth framework\?"


On 19/07/2017 11:06, Pavel Sanda wrote:

I disagree though that we should ban needauth mechanism right now and
if the argument really is that I can trick someone into unchecking
whatever I want, then I can directly trick him into writing rm -rf /
on the commandline.


+1, albeit quite evidently implicit from my side :-)!

T.

Re: Can shell-escape take advantage of needauth framework?


On 18/07/2017 21:50, Christian Ridderström wrote:

I do not know how many KGB/CIA agents will be willing attend the 'hack LyX' 
classes. How much is it worth on a spy resume ?


haha! something like that must have been said by someone in Redmond while coming out with 
this new brilliant and super-useful business-oriented automation feature called 
"Word Macro", before Melissa came out in 1999!

Personally, I wrote patent applications using LyX during one of my prior jobs in 
industry, and helped my colleagues into getting used to LyX, disregarding recommendations 
of my colleagues in that I should have used the "proper" .docx template... that 
can be conveniently edited using a much more secure program and OS?!?

Btw, +1 on threat analysis, and np with the minefield, even simply talking 
about security risks is being a good thing for LyX, and a few mines could 
already be spotted :-)!

Cheers,

T.

Re: Types of LyX users (Was: Can shell-escape take advantage of needauth framework?)


On 25/07/2017 00:15, Scott Kostyshak wrote:

Then we could easily say "I think this feature
would benefit Lucie, would hurt Raimundo, and would not affect Sara at


Alice was beginning to get very tired of sitting by her sister on the bank, and of having 
nothing to do: once or twice she had peeped into the book her sister was reading, but it had 
no pictures or conversations in it, "and what is the use of a book," thought Alice 
"without pictures or or conversations, or R scripts or automatically generated Gnuplot or 
Python plots?
So, Alice started to write a book using the wildly popular & largely known LyX text editor, allowing her to embed 
Animated contents and even interactive chats within chapters of her new book, which she loves to exchange with Bob the 
Lizzard. Although, Bob is used to write so fast, to get to annoy every one with its resounding theme sounds for each and 
every key press, to the point that Alice likes to send him chapters incorporating little jokingly hazardous scripts that, 
when previewed on the screen, cause Bob's sound volume to definitely shutdown (via removal of the snd-* ALSA drivers from 
the kernel through a root escalation exploit, but that's an unimportant technical detail). Bob would never try to preview 
nor compile those chapters, if it were not for the carefully placed and beautifully decorated "PUSH ME" labels 
that Alice placed on Bob's "View" button in the application Toolbar (if you're curious, other carefully crafted 
icons included "DRINK ME" and "ORANGE MARMELADE" in the same toolbar, all of them calling external 
'needauth' converters), when she helped out with LyX installation on his Linux box, quite a though task for a Lizard. So, 
there he goes, pressing that button over and over again through the day.
However, despite the apparent risks coming from the encrypted arguments of the Caterpillar, Alice 
and Bob didn't realize how much should they have been suspicious about the seemingly harmless and 
well-educated tea sessions they regularly had with Mallory the Mad Hatter, who used to like to 
confuse their little unaware friends with innocent paragraphs like: You might just as well say that 
"I see what I eat" is the same thing as "I eat what I see." Albeit literally 
interesting, Alice would fail to realize the full extent of the so big and remarkable differences 
in the font size between the two seemingly and confusingly self-resembling paragraphs, which, at a 
closer look (i.e., zoom at least 15000x in the preferences/settings pane), would indeed be 
recognized in their very nature of peculiar R and Gnuplot insets embedding scripts able to produce 
original hand-crafted output images with the contents just mentioned before, in addition to little, 
unforgettable changes to Alice and Bob home directories...

... hope you like it as a start ;-P ...

T.

Re: Types of LyX users (Was: Can shell-escape take advantage of needauth framework?)

2017-07-24 Thread Scott Kostyshak

On Sun, Jul 23, 2017 at 09:52:37PM +0200, Christian Ridderström wrote:

> I think Scott is partly verging towards the topic of types of users
> and user scenarios.

Yes I think so. The problem (as you mentioned) is that we really don't
know what the distribution of our users looks like.

> Perhaps there's more kinds of users?

I think your descriptions of users is very helpful, even more generally.
In fact, some companies assign a name to each type of users to make them
easy to reference. That might be useful for us to put in the
Development.lyx manual. Then we could easily say "I think this feature
would benefit Lucie, would hurt Raimundo, and would not affect Sara at
all," where Lucie, Raimundo, and Sara would be defined in the
development.lyx manual.

Scott

signature.asc
Description: PGP signature

Re: Can shell-escape take advantage of needauth framework?


[slowly catching up...]

On 18/07/2017 19:46, Christian Ridderström wrote:

I just did a test with gnuplot. In the LyX settings I had unchecked 'Forbid of 
use of needauth converters' and unchecked 'Use needauth option'. Then I opened 
a LyX doc with a gnuplot script. Result: LyX tried to run the script due to the 
preview, without asking or alerting me.


that's the purpose of the "Use needauth option", namely, allow for a workflow 
without burdens for those who know what they're doing, disabling needauth (which you did) 
just gets rid of the security measures, opens up your firewall, turns off security etc., 
compare with these other common software like a firewall or antivirus, if I go the its 
admin panel and turn it off...

What if, when unchecking that option, LyX would have popped up another dialog 
with a HUGE SECURITY warning ? I'm now feeling this would be needed.


In my opinion this demonstrates a case where the security is _not_ good enough, 
as I don't think it'd very difficult to trick someone into unchecking these 
boxes.


aware of the limitations of needauth, the final remedy was ...


- ?


sandboxing, as discussed in http://www.lyx.org/trac/ticket/10481, where there's 
a few notes about how to possibly design a portable mechanism across Win, Mac 
and Lin.

Thanks,

T.

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)

2017-07-24 Thread Scott Kostyshak

On Sat, Jul 22, 2017 at 01:09:09AM +0200, Jean-Marc Lasgouttes wrote:
> Le 21/07/2017 à 21:02, Scott Kostyshak a écrit :
> > > except if I disable needauth globally :(
> > 
> > What about editing the session file to add the paths of the .lyx files
> > that you want? If you're interested, I could write a Python/Bash script
> > that does it for you. I might end up using it also.
> 
> Well, I should not have to do that... Or it will be done automatically if I
> edit the file and try to typeset it, right?

Indeed. Rereading your question, I think I misunderstood it. I thought
you were looking for a way to get your scripts run without going through
the GUI for each one.

Scott

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)


On 23/07/2017 20:55, Christian Ridderström wrote:

Regarding setting something in the preference file manually: The only
thing I mind is that it adds a global state to LyX, as opposed to
starting LyX with some parameters. The global state would likely
affect e.g. testing.


the good thing is that we already have the -userdir command-line optionthat 
allows testing from a predictable initial state, doesn't it :-) ?
(AFAICR, extensively used in autotests for advanced F&R).

T.

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)


On 22/07/2017 00:47, Guenter Milde wrote:

Enrico's patch did not touch "needauth" but has some nice features for
"shell-escape": it addressed the "set and forget" issue by

a) adding a red icon to the status bar if a document has the "allow
shell-escape" flag.
   
b) revoking the permission, if the document is moved/copied to another

location.
   
I like the approach


+1, I like the idea of a visual feedback on the current security/trust status, 
e.g., it resembles the lock icon used in web browsers for https://.


From a user perspective, a common interface to "needauth" and "allow

shell escape" seems the best. "needauth" could actually take advantage of
Enrico's patch.


once I'll gain some spare time this summer, I'll try a merge :-)...


* Add "unsafe pdflatex" (== pdflatex --shell-escape) and "unsafe xelatex"
   as new converters requiring "needauth".


this sounds like something easy but already discussed and unliked/discarded.


* Allow per-converter permission settings (instead of one generic: "I
   trust/don't trust all unsafe converters").


the current system-wide setting is for all converters (disable any needauth,
allow them but warn me, allow them without constraints), whilst the memory
about trusted documents is per-document -- this makes sense because the
main source of untrust seems the document when coming from who knows where;
once the user acks that the doc is trusted, then we go without bugging the
user for each conversion. However, how would a per-converter settings
work, and how could I trust unconditionally, let's say, a R kneave/sweave
inset in a LyX doc coming from unknown sources, while at the same time
trust that an embedded gnuplot script or shell-escape command would not
delete my home folder ?


* Give users the possibility to check scripts before allowing to run them
   with shell-escape or at least list all parts of the document that will be
   allowed to run in unsafe mode
   (e.g. all gnuplot scripts for "gnuplot allowed", all ERT, preamble,
   document classes and packages for latex with shell escape).


that sounds like a feature enhancement deserving an entry on Trac ?

T.

Types of LyX users (Was: Can shell-escape take advantage of needauth framework?)

2017-07-23 Thread Christian Ridderström

On 21 July 2017 at 22:12, Scott Kostyshak  wrote:
> On Tue, Jul 18, 2017 at 11:21:38AM +0200, Jean-Marc Lasgouttes wrote:
>> Le 18/07/2017 à 09:07, Scott Kostyshak a écrit :
>> > I was thinking about it from a different angle. I was only focused on
>> > what I thought was most secure, without even considering usability. As I
>> > mentioned in the thread asking for votes, I believe that we should focus
>> > completely on what is the most secure.
>>
>> Well, what is the most secure is to remove all sweave/gnuplot/minted code.
>> There is no point in looking at security without usability IMO.
>
> I see what you mean and I think most people would agree with your
> interpretation. I was taking the approach more of "under which proposal
> is the user least likely to run malicious code". In your scenario (let's
> remove all sweave/gnuplot/minted code), well sweave users would just
> never upgrade LyX and would lose any security-related improvements and
> would not have any of the protection that needauth provides. For minted
> users, they would have to do the '-shell-escape' dance and would have
> the risk of forgetting that they left a converter permanently changed.
> This is what I mean by "less secure". But I know that I'm thinking about
> things differently from others. I can understand the other perspective
> of security of "if a user uses only built-in LyX with no customizations,
> then they would be less likely to run malicious code". I just think the
> "if" in that statement is concerning.

I think Scott is partly verging towards the topic of types of users
and user scenarios.
IMHO these aspects are quite important factors when discussing
features, security, UI and what to include in a software.

What kind of user was I, perhaps the archetypical LyX user:
- Started using LyX while working on my PhD (back in 1997 or so, in
case it matters)
- Did not know LaTeX in advance, thought it might make sense with a
graphical frontend.
- Wrote articles etc in LyX, learned some LaTeX on the way, put stuff
in preamble and some ERT.
- Only added some converters to include TGIF images or something like that.
- Besides LaTeX, I never embedded code in the LyX document
- This user googles to find solutions.
- A more advanced version of this user might start asking question on
the users' list.
- LyX worked really well for what I was doing.


Another kind of user could be the "the supervisor/reviewer".
- The student has a supervisor or colleague that he'd like to review his work
- Only minor editing is expected of the reviewer, perhaps adding comments,
  perhaps fixing an error.
Note: My supervisor got printouts back then IIRC.

Related is the use case is when two or more people closely collaborate
on a document.
Perhaps they use version control to work on the same LyX document.
Or keep it on a network drive. Or on e.g. Dropbox. Doing this adds
requirements on LyX.


More advanced user:
- LyX is used to build the main document, perhaps there are child documents.
- Perhaps exporting/publishing to multiple different formats.
- The document pulls in information from external files, e.g.
.tex-files with data.
- However, .tex-files are updated externally to the use of LyX,
  so the user has to manage dependencies etc.

Then we have the kind of user for whom I don't have a name, nor know well:
- Includes LyX deeply in his work flow
- Embeds code to be executed, perhaps repeatedly, in his document
- Using LyX as an IDE to develop his "program"
- ?

Non-user:
- Like my girlfriend, who likes writing in LaTeX
- I tried to get her to use LyX but it didn't take
   - she e.g. didn't like having to go through the menus all the time
 she would've preferred being able to use the keyboard all the time.
 So using plain LaTeX was "easier".
- At some point I should get more details on this.

Perhaps there's more kinds of users?

Anyway, the connection with security and shell-escape etc is that only
one of these kinds of users would likely actually need to use
shell-escape, and that user is probably more capable. OTOH, maybe we
_want_ to make LyX a tool where using e.g. R from within LyX is a
really good experience.

If these categories are reasonable, it'd be interesting to know the
distribution of users.
/Christian

PS. These days I find myself writing work notes in Emacs' org-mode a
lot of the time, why?
- Speed. It's quicker to type/edit in LaTeX.
  Perhaps because LyX's keyboard isn't working so well for me on my
mac with a Swedish keyboard.
- I typically don't need so many formulas. Org-mode is fine for a few
formulas, including images.
- Sometimes I even embed executable code (MATLAB) in my org-mode file.
- Often I don't need pretty output.
- Very convenient with text-based files that work well with version control.
- Perhaps also related that I had to go through five years or so where
I was forced
  to write in Word, and it left me damaged.

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)

2017-07-23 Thread Christian Ridderström

On 19 July 2017 at 12:00, Jean-Marc Lasgouttes  wrote:
> Le 19/07/2017 à 07:48, Christian Ridderström a écrit :
>>
>> If user does not want all these warnings, he could disable them by
>> launching LyX with some option like "--do-not-warn-me-about-unsafe-setting".
>> Instead of having a checkbox for "don't tell me these things again".
>
>
> It has the same issues as the checkbox when one considers batch command line
> processing. People add the switch to the command line and forget about it.

IMHO a user who does batch processing is pretty advanced...

Regarding setting something in the preference file manually: The only
thing I mind is that it adds a global state to LyX, as opposed to
starting LyX with some parameters. The global state would likely
affect e.g. testing.

/Christian

> The requested operation requires the use of a converter from sweave to
> pdflatex:
> Rscript --verbose --no-save --no-restore $$s/scripts/lyxsweave.R $$p$$i
> $$p$$o $$e $$r
> This external program can execute arbitrary commands on your system,
> including dangerous ones, if instructed to do so by a maliciously crafted
> .lyx document.
> Your current preference settings forbid its execution.
> (To change this setting, go to Preferences ▹ File Handling ▹ Converters and
> uncheck Security ▹ Forbid needauth converters.)

That's a good message in my opinion, especially as it points out the
"including dangerous ones".

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)

2017-07-21 Thread Jean-Marc Lasgouttes


Le 21/07/2017 à 21:02, Scott Kostyshak a écrit :

except if I disable needauth globally :(


What about editing the session file to add the paths of the .lyx files
that you want? If you're interested, I could write a Python/Bash script
that does it for you. I might end up using it also.


Well, I should not have to do that... Or it will be done automatically 
if I edit the file and try to typeset it, right?


JMarc

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)

2017-07-21 Thread Guenter Milde

On 2017-07-19, Richard Heck wrote:
> On 07/19/2017 01:48 AM, Christian Ridderström wrote:
>> On 18 July 2017 at 23:49, Jean-Marc Lasgouttes > > wrote:
>> Le 18/07/2017 à 23:42, Christian Ridderström a écrit :

>> I think the default should be secure, and that the user should
>> have to do something actively to go into a dangerous mode.

>> Well, since you consider that turning off two options is not
>> active enough, I am not sure what to propose :)

>> The problem I see with only unchecking two check boxes are e.g.:
>> - Users uncheck settings all the time, it doesn't seem very "scary"
>> - In the settings dialog, the real implications of unchecking these
>> options
>>   did not seem sufficiently clear to me.
>>   So calling it "Allow yourself to be shot in the foot by converters"
>> would help;-)
>> - The setting is persistent, and easily forgotten

> This, I believe, was part of what was addressed by Enrico's patch. Or
> the idea behind it.

Enrico's patch did not touch "needauth" but has some nice features for
"shell-escape": it addressed the "set and forget" issue by

a) adding a red icon to the status bar if a document has the "allow
   shell-escape" flag.

b) revoking the permission, if the document is moved/copied to another
   location.

I like the approach, especially b) seems a good compromise between user
comfort and security.

>From a user perspective, a common interface to "needauth" and "allow
shell escape" seems the best. "needauth" could actually take advantage of
Enrico's patch.

Some ideas:

* Add "unsafe pdflatex" (== pdflatex --shell-escape) and "unsafe xelatex"
  as new converters requiring "needauth".

* Allow per-converter permission settings (instead of one generic: "I
  trust/don't trust all unsafe converters").

* clicking the red icon should take you to the dialogue allowing to
  revoke the unsafe permission.

* Give users the possibility to check scripts before allowing to run them
  with shell-escape or at least list all parts of the document that will be
  allowed to run in unsafe mode
  (e.g. all gnuplot scripts for "gnuplot allowed", all ERT, preamble,
  document classes and packages for latex with shell escape).

Günter

Re: Can shell-escape take advantage of needauth framework?

On Tue, Jul 18, 2017 at 11:21:38AM +0200, Jean-Marc Lasgouttes wrote:
> Le 18/07/2017 à 09:07, Scott Kostyshak a écrit :
> > I was thinking about it from a different angle. I was only focused on
> > what I thought was most secure, without even considering usability. As I
> > mentioned in the thread asking for votes, I believe that we should focus
> > completely on what is the most secure.
> 
> Well, what is the most secure is to remove all sweave/gnuplot/minted code.
> There is no point in looking at security without usability IMO.

I see what you mean and I think most people would agree with your
interpretation. I was taking the approach more of "under which proposal
is the user least likely to run malicious code". In your scenario (let's
remove all sweave/gnuplot/minted code), well sweave users would just
never upgrade LyX and would lose any security-related improvements and
would not have any of the protection that needauth provides. For minted
users, they would have to do the '-shell-escape' dance and would have
the risk of forgetting that they left a converter permanently changed.
This is what I mean by "less secure". But I know that I'm thinking about
things differently from others. I can understand the other perspective
of security of "if a user uses only built-in LyX with no customizations,
then they would be less likely to run malicious code". I just think the
"if" in that statement is concerning.

Scott

signature.asc
Description: PGP signature

Re: Can shell-escape take advantage of needauth framework?

On Wed, Jul 19, 2017 at 11:06:54AM +0200, Pavel Sanda wrote:

> and
> if the argument really is that I can trick someone into unchecking
> whatever I want, then I can directly trick him into writing rm -rf /
> on the commandline.

Good point. I guess we try to limit the number of ways a user can be
tricked, even if each way is on average just as easy to convince users
to do.

Similarly, without needauth we can still trick the user into adding
-shell-escape manually to the converter and running a particular
document.

Scott


signature.asc
Description: PGP signature

Re: Can shell-escape take advantage of needauth framework?

On Tue, Jul 18, 2017 at 11:32:24AM +0200, Guillaume MM wrote:

> I agree, but note that for printing this did not invalidate existing
> documents.

True that's indeed an important difference.

Scott


signature.asc
Description: PGP signature

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)

On Wed, Jul 19, 2017 at 12:00:52PM +0200, Jean-Marc Lasgouttes wrote:

> Which make me think that I did not try to check whether my nice scripts to
> process Sweave lyx file still have a chance to work. Oops! they won't

This is good. It shows the needauth implementation works.

> except if I disable needauth globally :(

What about editing the session file to add the paths of the .lyx files
that you want? If you're interested, I could write a Python/Bash script
that does it for you. I might end up using it also.

Scott

Re: Can shell-escape take advantage of needauth framework?

2017-07-20 Thread Guillaume MM


Le 19/07/2017 à 11:47, Pavel Sanda a écrit :

Guillaume MM wrote:

Le 18/07/2017 ?? 23:27, Jean-Marc Lasgouttes a écrit :

Le 18/07/2017 ?? 23:24, Christian Ridderström a écrit :

The threat model is one important aspect, but it's difficult for us to
know who uses LyX and in which industries. Or how many users there are at
all. And how many of them that use converters.  If we can achieve good
security we don't need to care about user / usage statistics though.

If we talk principles, I think we should aim for really good security and
then discuss compromises for what's not doable. But I do think we could
do a whole lot better than the current 'needauth'.


+1


You start driving me to the wall.


To clarify, this +1 is about the ideal approach to securing the UI.

For 2.3, like Jürgen, I vote for getting back to productivity quickly,
and I do not need to repeat what was to me the realistic solution for
meeting the beta deadline.


Where you have been when there was huge discussion about details of these
mechanisms with Tommasso?


The discussion was not about designing a secure UI for extending the
realm of unsafe converters. Needauth was a much needed improvement, and
I actually try not to be a PITA in general (really). Moreover, Helge had
said what had to be said about its limitations in terms of security.

And between us, I try to steer away from discussions on the list unless
really necessary, to the point that I have been avoiding making
developments which I knew would involve discussions :( I mean, look at
the thread I found back in the archives exactly during the time frame of
the needauth discussion:
.
Do you think that I am incited me to contribute to discussions more than
is really necessary when they tend to become this embarrassing and
everybody acts as if this is normal?




Meep! Principle 1: "Things don???t become unsafe all by themselves
(Explicit authority)". This means in particular: the secure settings are
the default.


Yep. Isn't it the case with needauth right now?


Indeed, this is how needauth increased security.

Thank you for your involvement in the thread.

Guillaume

Re: Can shell-escape take advantage of needauth framework?

2017-07-20 Thread Guillaume MM


Le 19/07/2017 à 16:47, Richard Heck a écrit :

On 07/19/2017 05:06 AM, Pavel Sanda wrote:

Christian Ridderström wrote:

I just did a test with gnuplot. In the LyX settings I had unchecked 'Forbid
of use of needauth converters' and unchecked 'Use needauth option'. Then I
opened a LyX doc with a gnuplot script. Result: LyX tried to run the script
due to the preview, without asking or alerting me.

In my opinion this demonstrates a case where the security is _not_ good
enough, as I don't think it'd very difficult to trick someone into
unchecking these boxes.

I think at the end it boils down to the question whether we rather want
LyX for unaware users who can't handle any responsibility or we want
to allow advanced features for more hackish crowd of people.

I obviously stay in the hackish campground ground but understand your
fear for the poor.

I would offer two quick options here:
1. Rename 'Forbid of use of needauth converters' to something scary
so users have red flag.
2. Let the machinery alive, but move the flags from UI to RC files,
and forcing people to edit them, so they have time to think
what they are doing instead of randomly clicking.


I've suggested this, too. Just to be clear, you just have to remove the
UI for this setting. It
can stay in the same file, which can just be edited.



Not sure if what is being discussed is for 2.3 or for an ideal 
implementation, but ideally what about:


1. No "needauth" preferences (do not allow needauth from being disabled).
2. The dialog has a checkbox "I have read the above and I understand the
consequences", unchecked by default, which one has to check before
clicking "allow" or "always allow for the document". This checkbox is
remembered per-user (this replaces the "forbid use of needauth" option).
3. For command-line only (without GUI), have a command-line options
--needauth=[never(default)|always|ask].

Assuming other principles are implemented (visibility, revocability,
etc.), then IMO 2. is all we need as a secure GUI, and 3. all that is
needed for a secure command line (for a needauth implementation that
satisfies other principles).

Re: Can shell-escape take advantage of needauth framework?

2017-07-19 Thread Richard Heck

On 07/19/2017 05:06 AM, Pavel Sanda wrote:
> Christian Ridderström wrote:
>> I just did a test with gnuplot. In the LyX settings I had unchecked 'Forbid
>> of use of needauth converters' and unchecked 'Use needauth option'. Then I
>> opened a LyX doc with a gnuplot script. Result: LyX tried to run the script
>> due to the preview, without asking or alerting me.
>>
>> In my opinion this demonstrates a case where the security is _not_ good
>> enough, as I don't think it'd very difficult to trick someone into
>> unchecking these boxes.
> I think at the end it boils down to the question whether we rather want
> LyX for unaware users who can't handle any responsibility or we want
> to allow advanced features for more hackish crowd of people.
>
> I obviously stay in the hackish campground ground but understand your
> fear for the poor. 
>
> I would offer two quick options here:
> 1. Rename 'Forbid of use of needauth converters' to something scary
>so users have red flag.
> 2. Let the machinery alive, but move the flags from UI to RC files,
>and forcing people to edit them, so they have time to think
>what they are doing instead of randomly clicking.

I've suggested this, too. Just to be clear, you just have to remove the
UI for this setting. It
can stay in the same file, which can just be edited.

Rihcar

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)

2017-07-19 Thread Jean-Marc Lasgouttes


Le 19/07/2017 à 07:48, Christian Ridderström a écrit :
If user does not want all these warnings, he could disable them by 
launching LyX with some option like "--do-not-warn-me-about-unsafe-setting".

Instead of having a checkbox for "don't tell me these things again".


It has the same issues as the checkbox when one considers batch command 
line processing. People add the switch to the command line and forget 
about it.


Which make me think that I did not try to check whether my nice scripts 
to process Sweave lyx file still have a chance to work. Oops! they 
won't, except if I disable needauth globally :(


fantomas: LC_ALL=C ~/src/lyx/devbuild/src/lyx -e pdf2 cours-acp.lyx
Error: An external converter is disabled for security reasons

The requested operation requires the use of a converter from sweave to 
pdflatex:
Rscript --verbose --no-save --no-restore $$s/scripts/lyxsweave.R $$p$$i 
$$p$$o $$e $$r
This external program can execute arbitrary commands on your system, 
including dangerous ones, if instructed to do so by a maliciously 
crafted .lyx document.

Your current preference settings forbid its execution.
(To change this setting, go to Preferences ▹ File Handling ▹ Converters 
and uncheck Security ▹ Forbid needauth converters.)


JMarc

Re: Can shell-escape take advantage of needauth framework?

2017-07-19 Thread Pavel Sanda

Guillaume MM wrote:
> Le 18/07/2017 ?? 23:27, Jean-Marc Lasgouttes a écrit :
>> Le 18/07/2017 ?? 23:24, Christian Ridderström a écrit :
>>> The threat model is one important aspect, but it's difficult for us to 
>>> know who uses LyX and in which industries. Or how many users there are at 
>>> all. And how many of them that use converters.  If we can achieve good 
>>> security we don't need to care about user / usage statistics though.
>>>
>>> If we talk principles, I think we should aim for really good security and 
>>> then discuss compromises for what's not doable. But I do think we could 
>>> do a whole lot better than the current 'needauth'.
>
> +1

You start driving me to the wall.
Where you have been when there was huge discussion about details of these 
mechanisms with Tommasso?

> Meep! Principle 1: "Things don???t become unsafe all by themselves
> (Explicit authority)". This means in particular: the secure settings are
> the default.

Yep. Isn't it the case with needauth right now?

Pavel

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)

2017-07-19 Thread Pavel Sanda

Christian Ridderström wrote:
> - Users uncheck settings all the time, it doesn't seem very "scary"
> 
> Why does disabling something like needauth have to be done from within LyX?

... as I read through the list I see we come to similar conclusions ...
I don't have strong opinion about these.

Pavel

Re: Can shell-escape take advantage of needauth framework?

2017-07-19 Thread Pavel Sanda

Christian Ridderström wrote:
> I just did a test with gnuplot. In the LyX settings I had unchecked 'Forbid
> of use of needauth converters' and unchecked 'Use needauth option'. Then I
> opened a LyX doc with a gnuplot script. Result: LyX tried to run the script
> due to the preview, without asking or alerting me.
>
> In my opinion this demonstrates a case where the security is _not_ good
> enough, as I don't think it'd very difficult to trick someone into
> unchecking these boxes.

I think at the end it boils down to the question whether we rather want
LyX for unaware users who can't handle any responsibility or we want
to allow advanced features for more hackish crowd of people.

I obviously stay in the hackish campground ground but understand your
fear for the poor. 

I would offer two quick options here:
1. Rename 'Forbid of use of needauth converters' to something scary
   so users have red flag.
2. Let the machinery alive, but move the flags from UI to RC files,
   and forcing people to edit them, so they have time to think
   what they are doing instead of randomly clicking.

I disagree though that we should ban needauth mechanism right now and
if the argument really is that I can trick someone into unchecking
whatever I want, then I can directly trick him into writing rm -rf /
on the commandline.

Pavel

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)

2017-07-18 Thread Richard Heck

On 07/19/2017 01:48 AM, Christian Ridderström wrote:
>
> On 18 July 2017 at 23:49, Jean-Marc Lasgouttes  > wrote:
>
> Le 18/07/2017 à 23:42, Christian Ridderström a écrit :
>
> I think the default should be secure, and that the user should
> have to do something actively to go into a dangerous mode.
>
>
> Well, since you consider that turning off two options is not
> active enough, I am not sure what to propose :)
>
>
> The problem I see with only unchecking two check boxes are e.g.:
> - Users uncheck settings all the time, it doesn't seem very "scary"
> - In the settings dialog, the real implications of unchecking these
> options
>   did not seem sufficiently clear to me.
>   So calling it "Allow yourself to be shot in the foot by converters"
> would help;-)
> - The setting is persistent, and easily forgotten

This, I believe, was part of what was addressed by Enrico's patch. Or
the idea behind it.

It would at least be possible to have a 'hidden' setting here: One you
could activate only by
editing the preferences file. That doesn't seem unreasonable to me. This
is definitely a feature
for power users. Of course, that would make it even more difficult to undo.

> If it has to be done from within LyX, then perhaps do some of the
> things below to make being in unsafe mode more difficult to forget:
> - When unchecking the boxes, display a dialog informing them that
> they're going into dangerous territory.
> - Show the warning each time LyX is started, forcing the user to
> acknowledge it.
>   And make it so that user with a single click can reenable needauth.
> - Possibly show the dialog each time before building a document

One or the other here is enough, I'd think. But this is otherwise
similar to a suggestion
I made elsewhere.

> - Enable a strong/annoying visual indication/reminder that you're
> unsafe mode

Also part of Enrico's patch idea, I believe.

The overall idea behind that patch was to make this setting per-document
and easy to
change, with a strong visual indication. Making it non-persistent, or at
least something
you have to acknowledge each session, would add security. Here again, if
that seems too
annoying, a power-user-only non-gui setting could be considered. Then
it's possible for
people to sidestep the security, but only by really getting their hands
dirty.

Richard

Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)

On 18 July 2017 at 23:49, Jean-Marc Lasgouttes  wrote:

> Le 18/07/2017 à 23:42, Christian Ridderström a écrit :
>
>> I think the default should be secure, and that the user should have to do
>> something actively to go into a dangerous mode.
>>
>
> Well, since you consider that turning off two options is not active
> enough, I am not sure what to propose :)


The problem I see with only unchecking two check boxes are e.g.:
- Users uncheck settings all the time, it doesn't seem very "scary"
- In the settings dialog, the real implications of unchecking these options
  did not seem sufficiently clear to me.
  So calling it "Allow yourself to be shot in the foot by converters" would
help;-)
- The setting is persistent, and easily forgotten

As an aside, I think that if the user had to launch LyX from a terminal
with a parameter instead of just unchecking, the user would think he's
doing something really advanced/scary. Simply because he's not used to the
terminal.

Why does disabling something like needauth have to be done from within LyX?

If it has to be done from within LyX, then perhaps do some of the things
below to make being in unsafe mode more difficult to forget:
- When unchecking the boxes, display a dialog informing them that they're
going into dangerous territory.
- Show the warning each time LyX is started, forcing the user to
acknowledge it.
  And make it so that user with a single click can reenable needauth.
- Enable a strong/annoying visual indication/reminder that you're unsafe
mode
- Possibly show the dialog each time before building a document

If user does not want all these warnings, he could disable them by
launching LyX with some option like "--do-not-warn-me-about-unsafe-setting".
Instead of having a checkbox for "don't tell me these things again".


> So one question is how much R code or similar you have in typical
>> documents.
>>
>
> My typical documents are what I do for my data analysis course, where all
> the computation is done when typesetting the file (using Sweave). So, yes,
> I kind of rely on it.
>

Could you send me (privately) one of your docs with "a lot" of R source?
I'd like to see what it looks like and how much code we're talking about.

/Christian

>
>

Re: Can shell-escape take advantage of needauth framework?

2017-07-18 Thread Guillaume MM


Le 18/07/2017 à 23:27, Jean-Marc Lasgouttes a écrit :

Le 18/07/2017 à 23:24, Christian Ridderström a écrit :
The threat model is one important aspect, but it's difficult for us to 
know who uses LyX and in which industries. Or how many users there are 
at all. And how many of them that use converters.  If we can achieve 
good security we don't need to care about user / usage statistics though.


If we talk principles, I think we should aim for really good security 
and then discuss compromises for what's not doable. But I do think we 
could do a whole lot better than the current 'needauth'.


+1



As I wrote privately, we could have a page describing how to make LyX 
secure. Or even provide a compilation flag that removes dangerous features:

- disable needauth files
- somewhat limit what is read from the user directory to the bare minimum.

JMarc



Meep! Principle 1: "Things don’t become unsafe all by themselves
(Explicit authority)". This means in particular: the secure settings are
the default.

More generally, about the discussion becoming "crazy": academics have
come up with principles that everybody can apply for designing secure
UIs (we do trust them on this list, do we? ;). I see several virtues to
starting from such principles: this keeps the discussion focused, we do
not reinvent the wheel, we do not need to do guesswork on who are the
users and their threat vectors (whether they work in a philosophy
department or a P4 lab :).

Even considering this, I agree that this looks like a heavy discussion,
and I did not imagine it taking place between feature-freeze and beta
release. But if Scott decides to take the time to get to a good
implementation of needauth for 2.3, he will deserve credit for this.

(To add to the list: the "shoot yourself in the foot" option should be
removed IMO.)

Re: Can shell-escape take advantage of needauth framework?


Le 18/07/2017 à 23:24, Christian Ridderström a écrit :
The threat model is one important aspect, but it's difficult for us to 
know who uses LyX and in which industries. Or how many users there are 
at all. And how many of them that use converters.  If we can achieve 
good security we don't need to care about user / usage statistics though.


If we talk principles, I think we should aim for really good security 
and then discuss compromises for what's not doable. But I do think we 
could do a whole lot better than the current 'needauth'.


As I wrote privately, we could have a page describing how to make LyX 
secure. Or even provide a compilation flag that removes dangerous features:

- disable needauth files
- somewhat limit what is read from the user directory to the bare minimum.

JMarc

Re: Can shell-escape take advantage of needauth framework?

On 18 July 2017 at 22:09, Jean-Marc Lasgouttes  wrote:

> Le 18/07/2017 à 21:50, Christian Ridderström a écrit :
>
>> That you argue this way makes me sad.. and embarrassed/ashamed on behalf
>> of the project.  I could counter all your points in the paragraph above,
>> but I worry it's a waste of time and to be perfectly honest I'm a little to
>> upset right now to continue this discussion.
>>
>
> Wow, I just stepped on a mine. I'll retreat from the mine field before
> causing more harm, then.
>

My apologies for blowing up on you!
My only excuse is that we have different experiences, and .. uh... perhaps
it's related to lack of sleep due to my daughter waking every hour last
night. Yes, that might be a factor.

So please keep stomping into the minefield.

The threat model is one important aspect, but it's difficult for us to know
who uses LyX and in which industries. Or how many users there are at all.
And how many of them that use converters.  If we can achieve good security
we don't need to care about user / usage statistics though.

If we talk principles, I think we should aim for really good security and
then discuss compromises for what's not doable. But I do think we could do
a whole lot better than the current 'needauth'.

Sincere regards,
/Christian

Re: Can shell-escape take advantage of needauth framework?


Le 18/07/2017 à 21:50, Christian Ridderström a écrit :
That you argue this way makes me sad.. and embarrassed/ashamed on behalf 
of the project.  I could counter all your points in the paragraph above, 
but I worry it's a waste of time and to be perfectly honest I'm a little 
to upset right now to continue this discussion.


Wow, I just stepped on a mine. I'll retreat from the mine field before 
causing more harm, then.


JMarc

Re: Can shell-escape take advantage of needauth framework?

On 18 July 2017 at 21:15, Jean-Marc Lasgouttes  wrote:

> Le 18/07/2017 à 19:46, Christian Ridderström a écrit :
>
>> I just did a test with gnuplot. In the LyX settings I had unchecked
>> 'Forbid of use of needauth converters' and unchecked 'Use needauth option'.
>> Then I opened a LyX doc with a gnuplot script. Result: LyX tried to run the
>> script due to the preview, without asking or alerting me.
>>
>> In my opinion this demonstrates a case where the security is _not_ good
>> enough, as I don't think it'd very difficult to trick someone into
>> unchecking these boxes.
>>
>
> You may want to rename one of these options "shoot yourself in the foot".
>

You're joking, but I think you're correct. The labels for these options are
not sufficiently clear, the term "needauth" isn't very ... terrifying ;-)

> Seriously, one thing I learned about security is that the size of the lock
> you use should be related to the threat you are fearing.

Yes, you are quite right about this. Another is aspect is the effort
required to implement the attack and the probability of success. Here it's
not a lot of development time required to produce a malicious payload. It
remains only to trick the user into running the document, which is
something accomplished actors are already experienced at.

> Do we really work on the scenario where someone (CIA? KGB?) will be trying
> to trick a LyX user (how many of users are a worthy target?) into changing
> its own preferences in order to –let's say– steal all the readable files on
> the user directory. IMO,  if a hacker is ready to do this (including social
> engineering), the user will have other problems than the brand new needauth
> feature of the obscure editor LyX.

> I do not know how many KGB/CIA agents will be willing attend the 'hack
> LyX' classes. How much is it worth on a spy resume ?
>
> We should start by understanding what are the reasonable threats we want
> to fight against. This discussion is becoming crazy.
>

That you argue this way makes me sad.. and embarrassed/ashamed on behalf of
the project.  I could counter all your points in the paragraph above, but I
worry it's a waste of time and to be perfectly honest I'm a little to upset
right now to continue this discussion.

/Christian

Re: Can shell-escape take advantage of needauth framework?


Le 18/07/2017 à 19:46, Christian Ridderström a écrit :
I just did a test with gnuplot. In the LyX settings I had unchecked 
'Forbid of use of needauth converters' and unchecked 'Use needauth 
option'. Then I opened a LyX doc with a gnuplot script. Result: LyX 
tried to run the script due to the preview, without asking or alerting me.


In my opinion this demonstrates a case where the security is _not_ good 
enough, as I don't think it'd very difficult to trick someone into 
unchecking these boxes.


You may want to rename one of these options "shoot yourself in the foot".

Seriously, one thing I learned about security is that the size of the 
lock you use should be related to the threat you are fearing. Do we 
really work on the scenario where someone (CIA? KGB?) will be trying to 
trick a LyX user (how many of users are a worthy target?) into changing 
its own preferences in order to –let's say– steal all the readable files 
on the user directory. IMO,  if a hacker is ready to do this (including 
social engineering), the user will have other problems than the brand 
new needauth feature of the obscure editor LyX.


I do not know how many KGB/CIA agents will be willing attend the 'hack 
LyX' classes. How much is it worth on a spy resume ?


We should start by understanding what are the reasonable threats we want 
to fight against. This discussion is becoming crazy.


JMarc

Re: Can shell-escape take advantage of needauth framework?

On 18 July 2017 at 11:32, Guillaume MM  wrote:

> Once it is in, then it
>>> has to be supported forever, I believe there is an agreement about this.
>>>
>>
>> I wouldn't say this in absolute terms, but I would agree that there's
>> lots of hesitation before removing a feature, and that hesitation only
>> increases with time. But not that we have removed features. For example,
>> we removed support for printing, even though there were still some using
>> the feature.
>>
>
> I agree, but note that for printing this did not invalidate existing
> documents.

I just did a test with gnuplot. In the LyX settings I had unchecked 'Forbid
of use of needauth converters' and unchecked 'Use needauth option'. Then I
opened a LyX doc with a gnuplot script. Result: LyX tried to run the script
due to the preview, without asking or alerting me.

In my opinion this demonstrates a case where the security is _not_ good
enough, as I don't think it'd very difficult to trick someone into
unchecking these boxes.

I therefore think we should discuss the pros/cons of needauth. If needauth
cannot be shown to be secure enough, or if we don't think we can reasonably
fix it, then my opinion is that we should discuss removing needauth.

Presumably the number of users needing R/knitr/sweave is small compared to
the total user base and I don't think it's fair to leave the majority at
risk.

At the same time I definitely think that users should be able to build
their old documents in new releases of LyX.

So, if needauth cannot be shown to be good enough, how can we support users
of R etc?
Some alternatives:

- Require that they, for these documents, stay with the 2.2.x-series, until
we have a sufficiently good security mechanism.

- Only allow the dangerous behaviour of 2.2.x if the user starts LyX 2.3.0
with a special flag.

- Force them to compile their own LyX with a special flag set.

- ?

Regards,
Christian

Re: Can shell-escape take advantage of needauth framework?

2017-07-18 Thread Guillaume MM


Le 18/07/2017 à 09:07, Scott Kostyshak a écrit :

On the contrary, if preview never uses needauth converters, is it as
useful in cases like gnuplot?


By "it" do you mean the external template?


Yes


Once it is in, then it
has to be supported forever, I believe there is an agreement about this.


I wouldn't say this in absolute terms, but I would agree that there's
lots of hesitation before removing a feature, and that hesitation only
increases with time. But not that we have removed features. For example,
we removed support for printing, even though there were still some using
the feature.


I agree, but note that for printing this did not invalidate existing
documents.

Re: Can shell-escape take advantage of needauth framework?

2017-07-18 Thread Enrico Forestieri

On Tue, Jul 18, 2017 at 03:06:57AM -0400, Scott Kostyshak wrote:
> On Mon, Jul 17, 2017 at 02:14:39PM +0200, Enrico Forestieri wrote:
> > On Mon, Jul 17, 2017 at 07:14:07AM +0200, Guillaume MM wrote:
> > > 
> > > But besides that I agree with your suggestions. Thanks again for
> > > spending your time looking into this issue with so much care.
> > 
> > Yes, it seems that Scott can be easily convinced by your constructed
> > arguments.
> > 
> > "There is a bomb under our table, but we cannot remove it because it has
> > been there since 2011."
> 
> I think the situation is more like the following:
> 
> There is a bomb under the table. We could put another similar bomb or
> not put another similar bomb. Your argument is that if we don't put
> another bomb well we should remove the first bomb also.

Actually, my argument would be highlighting the application of double
standards in judgements.

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?


Le 18/07/2017 à 09:07, Scott Kostyshak a écrit :

I was thinking about it from a different angle. I was only focused on
what I thought was most secure, without even considering usability. As I
mentioned in the thread asking for votes, I believe that we should focus
completely on what is the most secure.


Well, what is the most secure is to remove all sweave/gnuplot/minted 
code. There is no point in looking at security without usability IMO.


Personally, I think it does not make sense to exclude features (as long 
as they are well supported and largely used) just on the ground of 
security. I understand that no everybody agrees with that.


I think that a clear marker that one is in unsafe mode would help. ut it 
should be something a bit annoying, like a box with read background 
indicating what unsafe features have been enabled at this time.


JMarc

Re: Can shell-escape take advantage of needauth framework?


Le 18/07/2017 à 09:07, Scott Kostyshak a écrit :

Once it is in, then it
has to be supported forever, I believe there is an agreement about this.


I wouldn't say this in absolute terms, but I would agree that there's
lots of hesitation before removing a feature, and that hesitation only
increases with time. But not that we have removed features. For example,
we removed support for printing, even though there were still some using
the feature.


LyX document format features and not the same as LyX UI features (note 
that I am not advocating removing anything).


JMarc

Re: Can shell-escape take advantage of needauth framework?

2017-07-18 Thread Scott Kostyshak

On Mon, Jul 17, 2017 at 07:14:07AM +0200, Guillaume MM wrote:
> Le 05/07/2017 à 06:54, Scott Kostyshak a écrit :
> > On Wed, Jun 28, 2017 at 02:37:41PM +0200, Guillaume MM wrote:
> > > Le 27/06/2017 à 21:00, Scott Kostyshak a écrit :
> > > > 
> > > > 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 in favour of treating lyx users like adults. To me, this means not
> > > reinventing the wheel and follow established guidelines. See e.g.
> > > 
> > > https://developer.apple.com/library/content/documentation/Security/Conceptual/SecureCodingGuide/Articles/AppInterfaces.html
> > > 
> > > and the paper they mention which has a lot of examples.
> > 
> > That's a great article. Thanks for the link. I've thought about a lot of
> > the principles mentioned in the article in the context of each of what I
> > view as the three options for moving forward:
> > 
> > 1. Revert the recently added minted support.
> > 
> > 2. Keep the current state of master.
> > 
> > 3. Apply the patch from [1].
> > 
> > Below, I will refer to these three options by their numbers above, e.g.
> > (1), (2), and (3).
> > 
> > Of course, the quotes I choose and my analysis of whether each option
> > "passes" or "fails" a criterion are completely subjective.
> > 
> > Starting at the section <>
> > 
> > "In many cases, a simpler interface is more secure, because the user is
> > less likely to ignore security features and less likely to make
> > mistakes."
> > 
> > (1) fails: implementing minted through custom preamble code and
> > ERT is not simple
> > 
> > (2) at least the user only needs to do the "shell-escape dance", which
> > is what I refer to going to
> > Tools > Preferences > File Handling > Converters, adding "-shell-escape"
> > (remembering whether "shell-escape" is preceded by one dash or two
> > dashes), clicking "Modify", and then finally clicking "Apply" or "Save"
> > (which I believe is a separate source of confusion for the users).
> > 
> > (3) passes: it is simple to read the dialog and click on the
> > button.
> > 
> > Moving on to the section <>
> > 
> > "The user must be made aware of when they are granting authorization to
> > some entity to act on their behalf or to gain access to their files or
> > data."
> > 
> > (1) fails: when the user does the "shell-escape dance" they are not
> > given any dialog making them aware of the potential dangers. You might
> > think "well they are adding it themselves so they should already know",
> > but I would say that most users are probably following some unofficial
> > guide they saw on the internet and just copy/pasting stuff in without
> > thinking.
> > 
> > (2) same as (1)
> > 
> > (3) passes: there is a dialog with an explanation.
> > 
> > "In this case, sharing should be off by default."
> > 
> > (1) - (3) all pass.
> > 
> > "If the user turns it on, the interface should make clear the extent to 
> > which remote users can
> > read from and write to files on the local system."
> > 
> > (1) fails: there is no dialog.
> > 
> > (2) fails: no dialog
> > 
> > (3) passes
> > 
> > "In addition, as long as sharing is on, there should be some clear
> > indication that it is on, lest users forget that their files are
> > accessible by others." (this was also brought up by Guillaume at [2])
> > 
> > (1) - (3) all fail.
> > 
> > I think that (3) has the most potential for implementing a visual
> > indication, unless we want to parse the converter command for
> > "shell-escape".
> > 
> > "Authorization should be revocable"
> > 
> > (1) passes
> > 
> > (2) passes
> > 
> > (3) fails: if the user puts "Always allow for this document", it is not
> > easy to revoke. The user must know something about the sessions file,
> > which they should not be expected to know. We could put instructions for
> > how to remove access. I'm not sure if I agree with adding even more text
> > to the dialog though. Tommaso mentioned some ideas regarding revocation
> > in the context of needauth at [3].
> > 
> > "Whenever possible, your program should not only make this possible, it
> > should make it easy to do."
> > 
> > (1) - (2) fail because of the "shell-escape dance" and (3) fails because
> > of the sessions file.
> > 
> > "You should also make it clear that revoking authorization cannot
> > reverse damage already done"
> > 
> > I don't understand this. In our case would this mean that if the user
> > removes "shell-escape" we give a dialog saying "the previous
> > compilations you did with this compiler could have run malicious code" ?
> > If so, I think that might confuse users more than benefit them.
> > 
> > Moving on to the section <>
> > 
> > Not much to talk about here. (3) does

Re: Can shell-escape take advantage of needauth framework?

2017-07-18 Thread Scott Kostyshak

On Mon, Jul 17, 2017 at 06:55:14AM +0200, Guillaume MM wrote:
> Hi Scott,
> 
> Sorry for the delay. I was very busy over the past
> two weeks.

No problem.

> Le 05/07/2017 à 06:54, Scott Kostyshak a écrit :
> > On Wed, Jun 28, 2017 at 02:36:49PM +0200, Guillaume MM wrote:
> > > Le 27/06/2017 à 23:45, Tommaso Cucinotta a écrit :
> > > > 
> > > > needauth was a urgently needed mitigation of the security issues behind
> > > > running
> > > > arbitrary external tools when compiling LyX documents; a more engineered
> > > > remedy
> > > > AFAICR was actually the use of sandboxing machineries, which was
> > > > prototyped on
> > > > Ubuntu/Linux using AppArmor.
> > > 
> > > This is also what I remember. The now secured converters were sweave and
> > > knitr, introduced in 2011 and 2012.
> > 
> > +1
> > 
> > > I see that you have also introduced a gnuplot converter with an example.
> > > 
> > > + Proportionality: unsafety is actually a main feature of gnuplot from
> > > what I understand from http://www.yqcomputer.com/320_2475_1.htm
> > > + Specificity: only gnuplot is given elevated privileges, which is what
> > > the user wants.
> > > - UI problem 1: When I open the example, I immediately get the needauth
> > > dialog for showing the preview. I thought we only wanted unsafe
> > > execution when compiling the document.
> > 
> > I forget what we decided on this. If we don't give the dialog, then we
> > should just disable the preview?
> 
> But then if I enable gnuplot for compilation, does it mean that preview
> becomes enabled? Then will this be remembered on next opening without
> asking? What if I change my mind later on / do not remember? etc.

I agree that we need to be careful with preview. Even if the user has
disabled needauth, I don't think we would want it to be possible for
malicious code to be run just from *opening* a .lyx document.

> On the contrary, if preview never uses needauth converters, is it as
> useful in cases like gnuplot?

By "it" do you mean the external template?

> > > It seems to me that needauth, as it is, is not ready for the addition of
> > > gnuplot. What do you think?
> > 
> > I'm not sure. Is it less secure than Sweave/knitr?
> 
> At the moment I believe it is less secure, because UI issues discussed
> above are more acute currently,

That could be, because with gnuplot perhaps preview is more likely. We
could just disable preview in the case of needauth converters.

> but mainly:
> 
> > Or is your argument
> > that those were already there so needauth makes them safer, but we
> > should not add any other converter that needs needauth?
> 
> Yes, this is what I believe is the safest route (see answers to your
> more specific points in the other message).

I see your logic here.

> I did not dare suggesting
> to remove features that were there since 2011.

> Once it is in, then it
> has to be supported forever, I believe there is an agreement about this.

I wouldn't say this in absolute terms, but I would agree that there's
lots of hesitation before removing a feature, and that hesitation only
increases with time. But not that we have removed features. For example,
we removed support for printing, even though there were still some using
the feature.

> This is also why I have been suggesting that the most careful choices
> are made from the start.

Makes sense.

Scott

Re: Can shell-escape take advantage of needauth framework?

2017-07-18 Thread Scott Kostyshak

On Mon, Jul 17, 2017 at 02:14:39PM +0200, Enrico Forestieri wrote:
> On Mon, Jul 17, 2017 at 07:14:07AM +0200, Guillaume MM wrote:
> > 
> > But besides that I agree with your suggestions. Thanks again for
> > spending your time looking into this issue with so much care.
> 
> Yes, it seems that Scott can be easily convinced by your constructed
> arguments.
> 
> "There is a bomb under our table, but we cannot remove it because it has
> been there since 2011."

I think the situation is more like the following:

There is a bomb under the table. We could put another similar bomb or
not put another similar bomb. Your argument is that if we don't put
another bomb well we should remove the first bomb also.

Scott

Re: Can shell-escape take advantage of needauth framework?

2017-07-17 Thread Enrico Forestieri

On Mon, Jul 17, 2017 at 07:14:07AM +0200, Guillaume MM wrote:
> 
> But besides that I agree with your suggestions. Thanks again for
> spending your time looking into this issue with so much care.

Yes, it seems that Scott can be easily convinced by your constructed
arguments.

"There is a bomb under our table, but we cannot remove it because it has
been there since 2011."

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?

2017-07-16 Thread Guillaume MM


Le 05/07/2017 à 06:54, Scott Kostyshak a écrit :

On Wed, Jun 28, 2017 at 02:37:41PM +0200, Guillaume MM wrote:

Le 27/06/2017 à 21:00, Scott Kostyshak a écrit :


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 in favour of treating lyx users like adults. To me, this means not
reinventing the wheel and follow established guidelines. See e.g.

https://developer.apple.com/library/content/documentation/Security/Conceptual/SecureCodingGuide/Articles/AppInterfaces.html

and the paper they mention which has a lot of examples.


That's a great article. Thanks for the link. I've thought about a lot of
the principles mentioned in the article in the context of each of what I
view as the three options for moving forward:

1. Revert the recently added minted support.

2. Keep the current state of master.

3. Apply the patch from [1].

Below, I will refer to these three options by their numbers above, e.g.
(1), (2), and (3).

Of course, the quotes I choose and my analysis of whether each option
"passes" or "fails" a criterion are completely subjective.

Starting at the section <>

"In many cases, a simpler interface is more secure, because the user is
less likely to ignore security features and less likely to make
mistakes."

(1) fails: implementing minted through custom preamble code and
ERT is not simple

(2) at least the user only needs to do the "shell-escape dance", which
is what I refer to going to
Tools > Preferences > File Handling > Converters, adding "-shell-escape"
(remembering whether "shell-escape" is preceded by one dash or two
dashes), clicking "Modify", and then finally clicking "Apply" or "Save"
(which I believe is a separate source of confusion for the users).

(3) passes: it is simple to read the dialog and click on the
button.

Moving on to the section <>

"The user must be made aware of when they are granting authorization to
some entity to act on their behalf or to gain access to their files or
data."

(1) fails: when the user does the "shell-escape dance" they are not
given any dialog making them aware of the potential dangers. You might
think "well they are adding it themselves so they should already know",
but I would say that most users are probably following some unofficial
guide they saw on the internet and just copy/pasting stuff in without
thinking.

(2) same as (1)

(3) passes: there is a dialog with an explanation.

"In this case, sharing should be off by default."

(1) - (3) all pass.

"If the user turns it on, the interface should make clear the extent to which 
remote users can
read from and write to files on the local system."

(1) fails: there is no dialog.

(2) fails: no dialog

(3) passes

"In addition, as long as sharing is on, there should be some clear
indication that it is on, lest users forget that their files are
accessible by others." (this was also brought up by Guillaume at [2])

(1) - (3) all fail.

I think that (3) has the most potential for implementing a visual
indication, unless we want to parse the converter command for
"shell-escape".

"Authorization should be revocable"

(1) passes

(2) passes

(3) fails: if the user puts "Always allow for this document", it is not
easy to revoke. The user must know something about the sessions file,
which they should not be expected to know. We could put instructions for
how to remove access. I'm not sure if I agree with adding even more text
to the dialog though. Tommaso mentioned some ideas regarding revocation
in the context of needauth at [3].

"Whenever possible, your program should not only make this possible, it
should make it easy to do."

(1) - (2) fail because of the "shell-escape dance" and (3) fails because
of the sessions file.

"You should also make it clear that revoking authorization cannot
reverse damage already done"

I don't understand this. In our case would this mean that if the user
removes "shell-escape" we give a dialog saying "the previous
compilations you did with this compiler could have run malicious code" ?
If so, I think that might confuse users more than benefit them.

Moving on to the section <>

Not much to talk about here. (3) does work as I expected when I tested
on the command line.

Moving on to the section <>

I think that (1) - (3) all fail this. Preferences and sessions files are
stored in plain text that can be easily edited. I think we could improve
this by storing them somewhere else where the user doesn't have
permissions, but I suppose we will always want to allow the user to
edit their preferences with an external editor, and backup/restore
preferences files. So I'm not sure if there's a feasible way to address
this.

I think that (3) fails this a little more than the others, because the
sessions file i

Re: Can shell-escape take advantage of needauth framework?

2017-07-16 Thread Guillaume MM


Hi Scott,

Sorry for the delay. I was very busy over the past
two weeks.

Le 05/07/2017 à 06:54, Scott Kostyshak a écrit :

On Wed, Jun 28, 2017 at 02:36:49PM +0200, Guillaume MM wrote:

Le 27/06/2017 à 23:45, Tommaso Cucinotta a écrit :


needauth was a urgently needed mitigation of the security issues behind
running
arbitrary external tools when compiling LyX documents; a more engineered
remedy
AFAICR was actually the use of sandboxing machineries, which was
prototyped on
Ubuntu/Linux using AppArmor.


This is also what I remember. The now secured converters were sweave and
knitr, introduced in 2011 and 2012.


+1


I see that you have also introduced a gnuplot converter with an example.

+ Proportionality: unsafety is actually a main feature of gnuplot from
what I understand from http://www.yqcomputer.com/320_2475_1.htm
+ Specificity: only gnuplot is given elevated privileges, which is what
the user wants.
- UI problem 1: When I open the example, I immediately get the needauth
dialog for showing the preview. I thought we only wanted unsafe
execution when compiling the document.


I forget what we decided on this. If we don't give the dialog, then we
should just disable the preview?


But then if I enable gnuplot for compilation, does it mean that preview
becomes enabled? Then will this be remembered on next opening without
asking? What if I change my mind later on / do not remember? etc.

On the contrary, if preview never uses needauth converters, is it as
useful in cases like gnuplot?

etc.




It seems to me that needauth, as it is, is not ready for the addition of
gnuplot. What do you think?


I'm not sure. Is it less secure than Sweave/knitr?


At the moment I believe it is less secure, because UI issues discussed
above are more acute currently, but mainly:


Or is your argument
that those were already there so needauth makes them safer, but we
should not add any other converter that needs needauth?


Yes, this is what I believe is the safest route (see answers to your
more specific points in the other message). I did not dare suggesting
to remove features that were there since 2011. Once it is in, then it
has to be supported forever, I believe there is an agreement about this.
This is also why I have been suggesting that the most careful choices
are made from the start.

Guillaume

Re: Can shell-escape take advantage of needauth framework?

2017-07-06 Thread Scott Kostyshak

On Thu, Jul 06, 2017 at 11:39:50PM +0200, Enrico Forestieri wrote:

> Then, I fear that whatever I say is ineffective.
> http://fablesofaesop.com/the-wolf-and-the-lamb.html

I'm really sorry you feel that way (I know this sounds insincere and
cliché, but this is how I feel).

Scott

signature.asc
Description: PGP signature

Re: Can shell-escape take advantage of needauth framework?

2017-07-06 Thread Enrico Forestieri

On Thu, Jul 06, 2017 at 04:20:43PM -0400, Scott Kostyshak wrote:
> On Thu, Jul 06, 2017 at 04:03:11PM +0200, Enrico Forestieri wrote:
> 
> > Trying to separate these issues is hypocritical and discriminatory.
> 
> I do not think it necessarily has to be hypocritical or discriminatory.
> Hypocritical to me would mean that there's no reasonable argument why
> one would be allowed and the other would not. Consider the following
> potential rule:
> 
>   We should not introduce code that makes the next LyX version less
>   secure than the previous version.
> 
> To me this is a reasonable criterion. I'm not saying it's the only one
> and I'm not saying it's better than other criteria we could use instead,
> but I believe it is *reasonable*. And because knitr and Sweave were in
> previous releases, unless we believe that needauth decreases the
> security of them then it passes this criterion. If it is determined that
> the work regarding shell-escape makes LyX less secure, then that work
> would not pass the above criteria.
> 
> Consider the following philosophy instead:
> 
>   If we reject a patch that decreases security, we should remove all
>   related functionality from LyX that suffers from that same security
>   threat.
> 
> This also seems reasonable. I'm not going to make an argument about
> which one is more reasonable. I'm just saying that both are reasonable
> to me.

Well, all of this smells of sophism to me. In this way everything and
its opposite can be justified by rethorical arguments.

> It is still not clear whether the majority of LyX developers think that
> the shell-escape work decreases or increases security. I would prefer to
> wait and see what the majority believe. If they believe that it would
> decrease security, then I think that we should do as you suggest and
> re-evaluate needauth and our decision to ship support for knitr and
> Sweave.

Oh, the tiranny of the majority. Then, I fear that whatever I say is
ineffective.
http://fablesofaesop.com/the-wolf-and-the-lamb.html

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?

2017-07-06 Thread Scott Kostyshak

On Thu, Jul 06, 2017 at 04:03:11PM +0200, Enrico Forestieri wrote:
> On Wed, Jul 05, 2017 at 12:54:20AM -0400, Scott Kostyshak wrote:
> 
> > On Tue, Jun 27, 2017 at 09:26:30PM +0200, Enrico Forestieri wrote:
> > 
> > > I don't think that reverting is in discussion here
> > 
> > It is as long as even one LyX developer proposes it.
> 
> Ok. Then, I find it unfair not discussing the removal of needauth and
> of the dangerous converters (gnuplot/sweave/knitr) at the same time.
> They are the same from a security point of view and thus they have
> to go together.

I see your point.

> Trying to separate these issues is hypocritical and discriminatory.

I do not think it necessarily has to be hypocritical or discriminatory.
Hypocritical to me would mean that there's no reasonable argument why
one would be allowed and the other would not. Consider the following
potential rule:

  We should not introduce code that makes the next LyX version less
  secure than the previous version.

To me this is a reasonable criterion. I'm not saying it's the only one
and I'm not saying it's better than other criteria we could use instead,
but I believe it is *reasonable*. And because knitr and Sweave were in
previous releases, unless we believe that needauth decreases the
security of them then it passes this criterion. If it is determined that
the work regarding shell-escape makes LyX less secure, then that work
would not pass the above criteria.

Consider the following philosophy instead:

  If we reject a patch that decreases security, we should remove all
  related functionality from LyX that suffers from that same security
  threat.

This also seems reasonable. I'm not going to make an argument about
which one is more reasonable. I'm just saying that both are reasonable
to me.

It is still not clear whether the majority of LyX developers think that
the shell-escape work decreases or increases security. I would prefer to
wait and see what the majority believe. If they believe that it would
decrease security, then I think that we should do as you suggest and
re-evaluate needauth and our decision to ship support for knitr and
Sweave.

Scott

Re: Can shell-escape take advantage of needauth framework?

2017-07-06 Thread Enrico Forestieri

On Wed, Jul 05, 2017 at 12:54:20AM -0400, Scott Kostyshak wrote:

> On Tue, Jun 27, 2017 at 09:26:30PM +0200, Enrico Forestieri wrote:
> 
> > I don't think that reverting is in discussion here
> 
> It is as long as even one LyX developer proposes it.

Ok. Then, I find it unfair not discussing the removal of needauth and
of the dangerous converters (gnuplot/sweave/knitr) at the same time.
They are the same from a security point of view and thus they have
to go together.

Trying to separate these issues is hypocritical and discriminatory.

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?

2017-07-05 Thread Jean-Marc Lasgouttes


Le 05/07/2017 à 06:54, Scott Kostyshak a écrit :

Moving on to the section <>

I think that (1) - (3) all fail this. Preferences and sessions files are
stored in plain text that can be easily edited. I think we could improve
this by storing them somewhere else where the user doesn't have
permissions, but I suppose we will always want to allow the user to
edit their preferences with an external editor, and backup/restore
preferences files. So I'm not sure if there's a feasible way to address
this.


LyX cannot store files in a place where the user does not have write 
permission, since it runs with these same permissions.


A solution might be to place file in a file with a random name, like 
firefox does with profiles, but then it is easy to parse profile.ini (or 
something like that) and find the profile name.


JMarc

Re: Can shell-escape take advantage of needauth framework?

2017-07-04 Thread Scott Kostyshak

On Wed, Jun 28, 2017 at 02:36:49PM +0200, Guillaume MM wrote:
> Le 27/06/2017 à 23:45, Tommaso Cucinotta a écrit :
> > 
> > needauth was a urgently needed mitigation of the security issues behind
> > running
> > arbitrary external tools when compiling LyX documents; a more engineered
> > remedy
> > AFAICR was actually the use of sandboxing machineries, which was
> > prototyped on
> > Ubuntu/Linux using AppArmor.
> 
> This is also what I remember. The now secured converters were sweave and
> knitr, introduced in 2011 and 2012.

+1

> I see that you have also introduced a gnuplot converter with an example.
> 
> + Proportionality: unsafety is actually a main feature of gnuplot from
> what I understand from http://www.yqcomputer.com/320_2475_1.htm
> + Specificity: only gnuplot is given elevated privileges, which is what
> the user wants.
> - UI problem 1: When I open the example, I immediately get the needauth
> dialog for showing the preview. I thought we only wanted unsafe
> execution when compiling the document.

I forget what we decided on this. If we don't give the dialog, then we
should just disable the preview?

> It seems to me that needauth, as it is, is not ready for the addition of
> gnuplot. What do you think?

I'm not sure. Is it less secure than Sweave/knitr? Or is your argument
that those were already there so needauth makes them safer, but we
should not add any other converter that needs needauth?

Scott


signature.asc
Description: PGP signature

Re: Can shell-escape take advantage of needauth framework?

2017-07-04 Thread Scott Kostyshak

On Tue, Jun 27, 2017 at 09:26:30PM +0200, Enrico Forestieri wrote:

> I don't think that reverting is in discussion here

It is as long as even one LyX developer proposes it.

Scott


signature.asc
Description: PGP signature

Re: Can shell-escape take advantage of needauth framework?

2017-07-04 Thread Scott Kostyshak

On Wed, Jun 28, 2017 at 02:37:41PM +0200, Guillaume MM wrote:
> Le 27/06/2017 à 21:00, Scott Kostyshak a écrit :
> > 
> > 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 in favour of treating lyx users like adults. To me, this means not
> reinventing the wheel and follow established guidelines. See e.g.
> 
> https://developer.apple.com/library/content/documentation/Security/Conceptual/SecureCodingGuide/Articles/AppInterfaces.html
> 
> and the paper they mention which has a lot of examples.

That's a great article. Thanks for the link. I've thought about a lot of
the principles mentioned in the article in the context of each of what I
view as the three options for moving forward:

1. Revert the recently added minted support.

2. Keep the current state of master.

3. Apply the patch from [1].

Below, I will refer to these three options by their numbers above, e.g.
(1), (2), and (3).

Of course, the quotes I choose and my analysis of whether each option
"passes" or "fails" a criterion are completely subjective.

Starting at the section <>

"In many cases, a simpler interface is more secure, because the user is
less likely to ignore security features and less likely to make
mistakes."

(1) fails: implementing minted through custom preamble code and
ERT is not simple

(2) at least the user only needs to do the "shell-escape dance", which
is what I refer to going to
Tools > Preferences > File Handling > Converters, adding "-shell-escape"
(remembering whether "shell-escape" is preceded by one dash or two
dashes), clicking "Modify", and then finally clicking "Apply" or "Save"
(which I believe is a separate source of confusion for the users).

(3) passes: it is simple to read the dialog and click on the
button.

Moving on to the section <>

"The user must be made aware of when they are granting authorization to
some entity to act on their behalf or to gain access to their files or
data."

(1) fails: when the user does the "shell-escape dance" they are not
given any dialog making them aware of the potential dangers. You might
think "well they are adding it themselves so they should already know",
but I would say that most users are probably following some unofficial
guide they saw on the internet and just copy/pasting stuff in without
thinking.

(2) same as (1)

(3) passes: there is a dialog with an explanation.

"In this case, sharing should be off by default."

(1) - (3) all pass.

"If the user turns it on, the interface should make clear the extent to which 
remote users can
read from and write to files on the local system."

(1) fails: there is no dialog.

(2) fails: no dialog

(3) passes

"In addition, as long as sharing is on, there should be some clear
indication that it is on, lest users forget that their files are
accessible by others." (this was also brought up by Guillaume at [2])

(1) - (3) all fail.

I think that (3) has the most potential for implementing a visual
indication, unless we want to parse the converter command for
"shell-escape".

"Authorization should be revocable"

(1) passes

(2) passes

(3) fails: if the user puts "Always allow for this document", it is not
easy to revoke. The user must know something about the sessions file,
which they should not be expected to know. We could put instructions for
how to remove access. I'm not sure if I agree with adding even more text
to the dialog though. Tommaso mentioned some ideas regarding revocation
in the context of needauth at [3].

"Whenever possible, your program should not only make this possible, it
should make it easy to do."

(1) - (2) fail because of the "shell-escape dance" and (3) fails because
of the sessions file.

"You should also make it clear that revoking authorization cannot
reverse damage already done"

I don't understand this. In our case would this mean that if the user
removes "shell-escape" we give a dialog saying "the previous
compilations you did with this compiler could have run malicious code" ?
If so, I think that might confuse users more than benefit them.

Moving on to the section <>

Not much to talk about here. (3) does work as I expected when I tested
on the command line.

Moving on to the section <>

I think that (1) - (3) all fail this. Preferences and sessions files are
stored in plain text that can be easily edited. I think we could improve
this by storing them somewhere else where the user doesn't have
permissions, but I suppose we will always want to allow the user to
edit their preferences with an external editor, and backup/restore
preferences files. So I'm not sure if there's a feasible way to address
this.

I think that (3) fails this a little more than the others, because the
sessions file is one more

Re: Can shell-escape take advantage of needauth framework?

2017-06-28 Thread Enrico Forestieri

On Wed, Jun 28, 2017 at 02:36:49PM +0200, Guillaume MM wrote:
> + Specificity: only gnuplot is given elevated privileges, which is what
> the user wants.

So, what? A system("whatever you want here") can be issued from a
gnuplot script. Then, one could say about shell-escape:

+ Specificity: only latex is given elevated privileges, which is what
  the user wants.

Please, stop hypocrisy.

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?

2017-06-28 Thread Guillaume MM


Le 27/06/2017 à 21:00, Scott Kostyshak a écrit :


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 in favour of treating lyx users like adults. To me, this means not 
reinventing the wheel and follow established guidelines. See e.g.


https://developer.apple.com/library/content/documentation/Security/Conceptual/SecureCodingGuide/Articles/AppInterfaces.html

and the paper they mention which has a lot of examples.



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.


What is your schedule in either case for implementing and testing the
changes?

Re: Can shell-escape take advantage of needauth framework?

2017-06-28 Thread Guillaume MM


Le 27/06/2017 à 23:45, Tommaso Cucinotta a écrit :


needauth was a urgently needed mitigation of the security issues behind 
running
arbitrary external tools when compiling LyX documents; a more engineered 
remedy
AFAICR was actually the use of sandboxing machineries, which was 
prototyped on

Ubuntu/Linux using AppArmor.


This is also what I remember. The now secured converters were sweave and
knitr, introduced in 2011 and 2012.

I see that you have also introduced a gnuplot converter with an example.

+ Proportionality: unsafety is actually a main feature of gnuplot from
what I understand from http://www.yqcomputer.com/320_2475_1.htm
+ Specificity: only gnuplot is given elevated privileges, which is what
the user wants.
- UI problem 1: When I open the example, I immediately get the needauth
dialog for showing the preview. I thought we only wanted unsafe
execution when compiling the document.
- UI problem 2: If I have N scripts in the document, I am asked N times
and must press no N times. It misses a "Never execute" button.

This is in addition to other needauth shortcomings in its current state
already mentioned.

It seems to me that needauth, as it is, is not ready for the addition of
gnuplot. What do you think?

Guillaume

Re: Can shell-escape take advantage of needauth framework?

On Wed, Jun 28, 2017 at 12:25:58AM +0200, Tommaso Cucinotta wrote:
> On 28/06/2017 00:02, Enrico Forestieri wrote:
> > ...and those converters can execute
> > arbitrary commands,
> 
> just to be sure, I just double-checked that on current trunk, without any
> settings in one's ~/.lyx/, the default behavior will be "Forbid use of
> needauth converters", so any of those dangerous ones would be disabled by
> default.

At the moment there is no shell escape added when using minted, so it is
even more secure.

> As for shell-escape, I couldn't go through the whole thread yet, but it seems
> very related, so it makes sense to be added as well. Whether in this release
> or next one, it's all up to the release master, though!

I am not interested in this support. Don't need it, simply. I was taken
perforce in this debate. I tried to do my best to address the concerns
of various people. When Jürgen raised this question, I told him that this
would have been the same as opening a pandora's box.

What I can't stand is that someone is asking for reverting support for
a feature which in itself is less dangerous than needauth. It is this
kind of hypocrisy which is unbearable.

> AFAICS, a reasonable (needauth-alike) behavior seems:
> - a document-specific setting tagging the document as one needing to run 
> latex with -shell-escape
> - only when trying to run latex (or pdflatex, if it supports -shell-escape, 
> or others), at the first attempt, trigger similar security questions as for 
> needauth:
>   a) the document needs to be compiled with this potentially harmful option, 
> are you sure you want to do that ? (y)es, (a)lways for this doc, (n)o [(r)un 
> without shell-escape ?]
>   b) have another set of settings similar to needauth ones (or re-use them ?) 
> that disable the question by default, so the user cannot choose (y)es unless 
> changes explicitly the settings
> - if one just opens the .lyx, makes edits, but never previews, nor needs to 
> run latex, then no question pops up.
> 
> Just quick thoughts, though.

I proposed about 5 different patches all taking more or less into account
all of what you are saying. Again, for taking into account various concerns,
not because I wanted to have support for shell escape. Now I stop it here.
If someone wants to add support for shell escape, he can freely reuse the
patches I posted. I am out now.

Thank you for your balanced suggestions.

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?

2017-06-27 Thread Tommaso Cucinotta


On 28/06/2017 00:02, Enrico Forestieri wrote:

...and those converters can execute
arbitrary commands,


just to be sure, I just double-checked that on current trunk, without any settings in 
one's ~/.lyx/, the default behavior will be "Forbid use of needauth 
converters", so any of those dangerous ones would be disabled by default.

As for shell-escape, I couldn't go through the whole thread yet, but it seems 
very related, so it makes sense to be added as well. Whether in this release or 
next one, it's all up to the release master, though!

AFAICS, a reasonable (needauth-alike) behavior seems:
- a document-specific setting tagging the document as one needing to run latex 
with -shell-escape
- only when trying to run latex (or pdflatex, if it supports -shell-escape, or 
others), at the first attempt, trigger similar security questions as for 
needauth:
  a) the document needs to be compiled with this potentially harmful option, 
are you sure you want to do that ? (y)es, (a)lways for this doc, (n)o [(r)un 
without shell-escape ?]
  b) have another set of settings similar to needauth ones (or re-use them ?) 
that disable the question by default, so the user cannot choose (y)es unless 
changes explicitly the settings
- if one just opens the .lyx, makes edits, but never previews, nor needs to run 
latex, then no question pops up.

Just quick thoughts, though.

Good night.

T.

Re: Can shell-escape take advantage of needauth framework?

On Tue, Jun 27, 2017 at 03:00:37PM -0400, Scott Kostyshak wrote:
> On Tue, Jun 27, 2017 at 03:33:12PM +0200, Guillaume MM wrote:
> >
> > 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.

I don't think that reverting is in discussion here, apart from the
(apparently, IMO) biased opinion of Guillame. The support for minted
is not risky in itself, otherwise any usage of generic latex packages
would be.

> Thanks for your logical arguments and your proposal.

Fuzzy logic, maybe. At the moment it is more risky the needauth option
than the minted support. But maybe I am forgetting that that was an
improvement. Ipse dixit .

--
Enrico

Re: Can shell-escape take advantage of needauth framework?

On Tue, Jun 27, 2017 at 11:45:56PM +0200, Tommaso Cucinotta wrote:
> On 20/06/2017 02:43, Guillaume MM wrote:
> > 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.
> 
> needauth was a urgently needed mitigation of the security issues behind 
> running
> arbitrary external tools when compiling LyX documents; a more engineered 
> remedy
> AFAICR was actually the use of sandboxing machineries, which was prototyped on
> Ubuntu/Linux using AppArmor.

I actually don't see where the urgency was. We were not distributing
dangerous converters. Instead, now we do and those converters can execute
arbitrary commands, so needauth is in the same board as shell escape and
trying to separate the two issues is only instrumental.

My 3c

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?

2017-06-27 Thread Tommaso Cucinotta


On 20/06/2017 02:43, Guillaume MM wrote:

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.


needauth was a urgently needed mitigation of the security issues behind running
arbitrary external tools when compiling LyX documents; a more engineered remedy
AFAICR was actually the use of sandboxing machineries, which was prototyped on
Ubuntu/Linux using AppArmor.


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.


+1 for completing the current needauth with a revocation means; this can include
also a security settings pane where we list the pathnames of all documents in
the user's approved permission list, where one can revoke the permission 
selectively,
or even perhaps edit the list and use wildcards (e.g., always grant when I work
in /home/tommaso/work/trusted/*)... ok, I went too far :-)

My2c,

T.

Re: Can shell-escape take advantage of needauth framework?

On Tue, Jun 27, 2017 at 03:00:37PM -0400, Scott Kostyshak wrote:
> On Tue, Jun 27, 2017 at 03:33:12PM +0200, Guillaume MM wrote:
> > 
> > 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.

I don't think that reverting is in discussion here, apart from the
(apparently, IMO) biased opinion of Guillame. The support for minted
is not risky in itself, otherwise any usage of generic latex packages
would be.

> Thanks for your logical arguments and your proposal.

Fuzzy logic, maybe. At the moment it is more risky the needauth option
than the minted support. But maybe I am forgetting that that was an
improvement. Ipse dixit .

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?

2017-06-27 Thread Scott Kostyshak

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 ad

Re: Can shell-escape take advantage of needauth framework?

On Tue, Jun 27, 2017 at 03:33:12PM +0200, Guillaume MM wrote:
> 
> 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 don't think that your opinion is sincere. I think that instead it
is again hypocritical. It was amusing reading that "I do not oppose
to needauth because it was an improvement, while shell escape is
a security hazard". They entail the same security risk, so either
you are really concerned about security or you are simply using
specious arguments. And i think that this last one is the case.
I was not specifically interested in minted support and was
actually encouraged in adding it. It seems that removing this
support is becoming the reason of your life for the simple pleasure
of hurting. I did not expect anything better from you, frankly.

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?

2017-06-27 Thread Guillaume MM


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 (I am abstract because it is not clear what else is
being discussed apart from minted.sty).

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.



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:

* 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).

Good luck.

Guillaume

Re: Can shell-escape take advantage of needauth framework?

2017-06-25 Thread Scott Kostyshak

On Sun, Jun 25, 2017 at 02:54:29PM +0200, Jürgen Spitzmüller wrote:
> Am Sonntag, den 25.06.2017, 13:53 +0200 schrieb Guillaume MM:
> > > 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
> > >  whether it would be
> > > hard
> > > to implement 3-step compilation in minted.sty.
> > > 
> > 
> > A quick update: there is now a reply on the ticket above. In addition
> > I 
> > received the following reply from the author of minted.sty.
> 
> Thanks for bringing this to Geoffrey's attention!

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.

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.

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

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?

Scott

signature.asc
Description: PGP signature

Re: Can shell-escape take advantage of needauth framework?

2017-06-25 Thread Jürgen Spitzmüller

Am Sonntag, den 25.06.2017, 13:53 +0200 schrieb Guillaume MM:
> > 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
> >  whether it would be
> > hard
> > to implement 3-step compilation in minted.sty.
> > 
> 
> A quick update: there is now a reply on the ticket above. In addition
> I 
> received the following reply from the author of minted.sty.

Thanks for bringing this to Geoffrey's attention!

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Can shell-escape take advantage of needauth framework?

2017-06-25 Thread Guillaume MM


Le 21/06/2017 à 07:15, Guillaume MM a écrit :


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
 whether it would be hard
to implement 3-step compilation in minted.sty.



A quick update: there is now a reply on the ticket above. In addition I 
received the following reply from the author of minted.sty.




I agree that -shell-escape is problematic, especially in a case like
LyX where the raw LaTeX code can be less visible. I will be happy to
add a 3-step compile option; the only issue will be finding time to
do it. I think the Python side of doing this would be trivial. The
main work would need to be in LaTeX code in minted.sty. I've provided
some additional technical details (if you want them) in the GitHub
issue.

Re: Can shell-escape take advantage of needauth framework?

2017-06-21 Thread Jürgen Spitzmüller

2017-06-21 10:16 GMT+02:00 Jean-Marc Lasgouttes :

> We could try something in the status bar.
>

I also thought about this, and I would prefer it much over a toolbar button.

Jürgen


>
> JMarc
>

Re: Can shell-escape take advantage of needauth framework?

2017-06-21 Thread Jean-Marc Lasgouttes


Le 21/06/2017 à 07:15, Guillaume MM a écrit :
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.


We could try something in the status bar.

JMarc

Re: Can shell-escape take advantage of needauth framework?

2017-06-20 Thread Guillaume MM

Le 20/06/2017 à 09:54, Jürgen Spitzmüller a écrit :

2017-06-20 2:43 GMT+02:00 Guillaume MM 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
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.

Re: Can shell-escape take advantage of needauth framework?

2017-06-20 Thread Enrico Forestieri

On Tue, Jun 20, 2017 at 08:48:20PM +0200, Jürgen Spitzmüller wrote:

> Am Dienstag, den 20.06.2017, 20:29 +0200 schrieb Enrico Forestieri:
> > Ok, so you want to support shell-escape only for supported packages.
> > The next iteration of the patch attached here allows this only for
> > documents actually using minted. When all minted listings are removed
> > from the document, the permission of using shell-escape is revoked,
> > whatever the choice of the Syntax Highlighting Package.
> 
> Thanks. I didn't check the patch in detail, but I like the approach.

The previous patch was revoking permission even when no listing was
left in the document during an editing session. The attached one
performs instead the check only when the document is closed.

-- 
Enrico
diff --git a/src/Converter.cpp b/src/Converter.cpp
index 6e10b18704..45b725e8c6 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -19,14 +19,18 @@
 #include "Encoding.h"
 #include "ErrorList.h"
 #include "Format.h"
+#include "InsetList.h"
 #include "Language.h"
 #include "LaTeX.h"
 #include "LyXRC.h"
 #include "Mover.h"
+#include "ParagraphList.h"
 #include "Session.h"
 
 #include "frontends/alert.h"
 
+#include "insets/InsetInclude.h"
+
 #include "support/debug.h"
 #include "support/FileNameList.h"
 #include "support/filetools.h"
@@ -279,20 +283,38 @@ OutputParams::FLAVOR 
Converters::getFlavor(Graph::EdgePath const & path,
 }
 
 
-bool Converters::checkAuth(Converter const & conv, string const & doc_fname)
+bool Converters::checkAuth(Converter const & conv, string const & doc_fname,
+  bool use_shell_escape)
 {
-   if (!conv.need_auth())
+   if (!conv.latex())
+   use_shell_escape = false;
+   if (!conv.need_auth() && !use_shell_escape)
return true;
-   const docstring security_warning = bformat(
- _("The requested operation requires the use of a converter 
from "
-   "%2$s to %3$s:"
+   string conv_command = conv.command();
+   bool const has_shell_escape = contains(conv_command, "-shell-escape");
+   size_t const token_pos = conv_command.find("$$");
+   bool const has_token = token_pos != string::npos;
+   string const command = use_shell_escape && !has_shell_escape
+   ? (has_token ? conv_command.insert(token_pos, "-shell-escape ")
+: conv_command.append(" -shell-escape"))
+   : conv_command;
+   docstring const security_warning = (use_shell_escape
+   ? bformat(_("This document uses minted listings, so the LaTeX "
+   "backend needs to be able to launch external programs:"
+   "%1$s"
+   "The external programs can execute arbitrary commands on "
+   "your system, including dangerous ones, if instructed to do "
+   "so by a maliciously crafted LyX document."),
+ from_utf8(command))
+   : bformat(_("The requested operation requires the use of a "
+   "converter from %2$s to %3$s:"
"%1$s"
-   "This external program can execute arbitrary commands on 
your "
-   "system, including dangerous ones, if instructed to do so by a "
-   "maliciously crafted .lyx document."),
- from_utf8(conv.command()), from_utf8(conv.from()),
- from_utf8(conv.to()));
-   if (lyxrc.use_converter_needauth_forbidden) {
+   "This external program can execute arbitrary commands on "
+   "your system, including dangerous ones, if instructed to do "
+   "so by a maliciously crafted LyX document."),
+ from_utf8(command), from_utf8(conv.from()),
+ from_utf8(conv.to(;
+   if (lyxrc.use_converter_needauth_forbidden && !use_shell_escape) {
frontend::Alert::error(
_("An external converter is disabled for security reasons"),
security_warning + _(
@@ -302,29 +324,43 @@ bool Converters::checkAuth(Converter const & conv, string 
const & doc_fname)
"Forbid needauth converters.)"), false);
return false;
}
-   if (!lyxrc.use_converter_needauth)
+   if (!lyxrc.use_converter_needauth && !use_shell_escape)
return true;
-   static const docstring security_title =
-   _("An external converter requires your authorization");
+   docstring const security_title = use_shell_escape
+   ? _("A LaTeX backend requires your authorization")
+   : _("An external converter requires your authorization");
int choice;
-   const docstring security_warning2 = security_warning +
-   _("Would you like to run this converter?"
- "Only run if you trust the origin/sender of the LyX "
- "document!");
+   docstring const security_warning2 = security_warning + (use_shell_escape
+

Re: Can shell-escape take advantage of needauth framework?

2017-06-20 Thread Enrico Forestieri

On Tue, Jun 20, 2017 at 03:44:10PM -0400, Richard Heck wrote:

> On 06/20/2017 02:48 PM, Jürgen Spitzmüller wrote:
> > Am Dienstag, den 20.06.2017, 20:29 +0200 schrieb Enrico Forestieri:
> >> Ok, so you want to support shell-escape only for supported packages.
> >> The next iteration of the patch attached here allows this only for
> >> documents actually using minted. When all minted listings are removed
> >> from the document, the permission of using shell-escape is revoked,
> >> whatever the choice of the Syntax Highlighting Package.
> > Thanks. I didn't check the patch in detail, but I like the approach.
> 
> So I'm following this from afar, and I understand the competing
> interests. But I wonder
> whether restricting the ability to do this too much will back us into
> the problem of people
> adding -shell-escape when using packages LyX doesn't directly support.
> Obviously, there
> is only so much we can do, but providing some mechanism by means of
> which people can
> turn this on and off easily in a per-document, per-session way makes
> some sense to me.

This was the approach taken in the patch I posted yesterday, which was
also giving a visual feedback about the fact. But there is no consensus,
seemingly, as this is deemed a security risk. We have to converge to a
lowest common denominator, which at the moment seems to be supporting
this only for supported packages.

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?

2017-06-20 Thread Richard Heck

On 06/20/2017 02:48 PM, Jürgen Spitzmüller wrote:
> Am Dienstag, den 20.06.2017, 20:29 +0200 schrieb Enrico Forestieri:
>> Ok, so you want to support shell-escape only for supported packages.
>> The next iteration of the patch attached here allows this only for
>> documents actually using minted. When all minted listings are removed
>> from the document, the permission of using shell-escape is revoked,
>> whatever the choice of the Syntax Highlighting Package.
> Thanks. I didn't check the patch in detail, but I like the approach.

So I'm following this from afar, and I understand the competing
interests. But I wonder
whether restricting the ability to do this too much will back us into
the problem of people
adding -shell-escape when using packages LyX doesn't directly support.
Obviously, there
is only so much we can do, but providing some mechanism by means of
which people can
turn this on and off easily in a per-document, per-session way makes
some sense to me.

Richard

Re: Can shell-escape take advantage of needauth framework?

2017-06-20 Thread Jürgen Spitzmüller

Am Dienstag, den 20.06.2017, 20:29 +0200 schrieb Enrico Forestieri:
> Ok, so you want to support shell-escape only for supported packages.
> The next iteration of the patch attached here allows this only for
> documents actually using minted. When all minted listings are removed
> from the document, the permission of using shell-escape is revoked,
> whatever the choice of the Syntax Highlighting Package.

Thanks. I didn't check the patch in detail, but I like the approach.

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Can shell-escape take advantage of needauth framework?

2017-06-20 Thread Enrico Forestieri

On Tue, Jun 20, 2017 at 09:26:53AM +0200, Jürgen Spitzmüller wrote:

> 2017-06-19 21:00 GMT+02:00 Enrico Forestieri :
> 
> > Are you able to tell that you need -shell-escape for the attached
> > document?
> >
> 
> No, but this is not a natively supported feature (as opposed to minted).

Ok, so you want to support shell-escape only for supported packages.
The next iteration of the patch attached here allows this only for
documents actually using minted. When all minted listings are removed
from the document, the permission of using shell-escape is revoked,
whatever the choice of the Syntax Highlighting Package.

-- 
Enrico
diff --git a/src/Converter.cpp b/src/Converter.cpp
index 6e10b18704..dd0cdd8779 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -19,14 +19,18 @@
 #include "Encoding.h"
 #include "ErrorList.h"
 #include "Format.h"
+#include "InsetList.h"
 #include "Language.h"
 #include "LaTeX.h"
 #include "LyXRC.h"
 #include "Mover.h"
+#include "ParagraphList.h"
 #include "Session.h"
 
 #include "frontends/alert.h"
 
+#include "insets/InsetInclude.h"
+
 #include "support/debug.h"
 #include "support/FileNameList.h"
 #include "support/filetools.h"
@@ -279,20 +283,38 @@ OutputParams::FLAVOR 
Converters::getFlavor(Graph::EdgePath const & path,
 }
 
 
-bool Converters::checkAuth(Converter const & conv, string const & doc_fname)
+bool Converters::checkAuth(Converter const & conv, string const & doc_fname,
+  bool use_shell_escape)
 {
-   if (!conv.need_auth())
+   if (!conv.latex())
+   use_shell_escape = false;
+   if (!conv.need_auth() && !use_shell_escape)
return true;
-   const docstring security_warning = bformat(
- _("The requested operation requires the use of a converter 
from "
-   "%2$s to %3$s:"
+   string conv_command = conv.command();
+   bool const has_shell_escape = contains(conv_command, "-shell-escape");
+   size_t const token_pos = conv_command.find("$$");
+   bool const has_token = token_pos != string::npos;
+   string const command = use_shell_escape && !has_shell_escape
+   ? (has_token ? conv_command.insert(token_pos, "-shell-escape ")
+: conv_command.append(" -shell-escape"))
+   : conv_command;
+   docstring const security_warning = (use_shell_escape
+   ? bformat(_("This document uses minted listings, so the LaTeX "
+   "backend needs to be able to launch external programs:"
+   "%1$s"
+   "The external programs can execute arbitrary commands on "
+   "your system, including dangerous ones, if instructed to do "
+   "so by a maliciously crafted LyX document."),
+ from_utf8(command))
+   : bformat(_("The requested operation requires the use of a "
+   "converter from %2$s to %3$s:"
"%1$s"
-   "This external program can execute arbitrary commands on 
your "
-   "system, including dangerous ones, if instructed to do so by a "
-   "maliciously crafted .lyx document."),
- from_utf8(conv.command()), from_utf8(conv.from()),
- from_utf8(conv.to()));
-   if (lyxrc.use_converter_needauth_forbidden) {
+   "This external program can execute arbitrary commands on "
+   "your system, including dangerous ones, if instructed to do "
+   "so by a maliciously crafted LyX document."),
+ from_utf8(command), from_utf8(conv.from()),
+ from_utf8(conv.to(;
+   if (lyxrc.use_converter_needauth_forbidden && !use_shell_escape) {
frontend::Alert::error(
_("An external converter is disabled for security reasons"),
security_warning + _(
@@ -302,29 +324,43 @@ bool Converters::checkAuth(Converter const & conv, string 
const & doc_fname)
"Forbid needauth converters.)"), false);
return false;
}
-   if (!lyxrc.use_converter_needauth)
+   if (!lyxrc.use_converter_needauth && !use_shell_escape)
return true;
-   static const docstring security_title =
-   _("An external converter requires your authorization");
+   docstring const security_title = use_shell_escape
+   ? _("A LaTeX backend requires your authorization")
+   : _("An external converter requires your authorization");
int choice;
-   const docstring security_warning2 = security_warning +
-   _("Would you like to run this converter?"
- "Only run if you trust the origin/sender of the LyX "
- "document!");
+   docstring const security_warning2 = security_warning + (use_shell_escape
+   ? _("Should LaTeX backends be allowed to run external "
+   "programs?Allow them only if you trust the "
+

Re: Can shell-escape take advantage of needauth framework?

2017-06-20 Thread Jürgen Spitzmüller

2017-06-20 2:43 GMT+02:00 Guillaume MM :

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

This is correct. 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.


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

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.


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

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.

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


> 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),
>

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.


> * 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).


> * What is trusted can change over time.
>

Sure.


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

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.


>
> Lastly, nobody seems to disagree that that encouraging users to add
> -shell-escape by hand permanently is even worse.
>

Of course it is!


>
> I do not know the differences in features between minted.sty and
> pygmentex.sty nor how long it would take to

Re: Can shell-escape take advantage of needauth framework?

2017-06-20 Thread Jürgen Spitzmüller

2017-06-19 21:00 GMT+02:00 Enrico Forestieri :

> Are you able to tell that you need -shell-escape for the attached
> document?
>

No, but this is not a natively supported feature (as opposed to minted).

Jürgen


>
> --
> Enrico
>

Re: Can shell-escape take advantage of needauth framework?

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

Re: Can shell-escape take advantage of needauth framework?

2017-06-19 Thread Guillaume MM


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 th

Re: Can shell-escape take advantage of needauth framework?

On Mon, Jun 19, 2017 at 09:00:33PM +0200, Enrico Forestieri wrote:

> On Mon, Jun 19, 2017 at 08:57:00PM +0200, Jürgen Spitzmüller wrote:
> 
> > Am Montag, den 19.06.2017, 20:33 +0200 schrieb Enrico Forestieri:
> > > Because we don't know whether it's needed?
> > 
> > Why not? Can't we define that?
> 
> Are you able to tell that you need -shell-escape for the attached
> document?

Now attached.

-- 
Enrico
#LyX 2.2 created this file. For more info see http://www.lyx.org/
\lyxformat 508
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass article
\begin_preamble
\usepackage[miktex,siunitx]{gnuplottex}
\usepackage{siunitx}

% Using pdflatex, the produced eps file is automatically converted
% to pdf using epstopdf by default. Unfortunately, the cairolatex
% terminal of gnuplot inserts a couple comment lines just before
% the line "%!PS-Adobe-3.0 EPSF-3.0" that characterizes an eps file.
% This confuses the epstopdf program that comes with MikTeX, which
% issues a "Invalid binary DOS header" error and produces an empty
% pdf file. The solution is using ps2pdf.
\usepackage{epstopdf}
\epstopdfDeclareGraphicsRule{.eps}{pdf}{.pdf}{%
ps2pdf -dEPSCrop #1 \OutputFile
}
\end_preamble
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\graphics default
\default_output_format pdf2
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize 12
\spacing single
\use_hyperref false
\papersize default
\use_geometry true
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\leftmargin 2cm
\topmargin 2cm
\rightmargin 2cm
\bottommargin 2cm
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Standard
\begin_inset Preview

\begin_layout Standard
\begin_inset ERT
status open

\begin_layout Plain Layout

\backslash
begin{gnuplot}[terminal=cairolatex,terminaloptions=lw 3]
\end_layout

\begin_layout Plain Layout

set title "The sinc function"
\end_layout

\begin_layout Plain Layout

set xlabel "Abscissa"
\end_layout

\begin_layout Plain Layout

set ylabel "Ordinate"
\end_layout

\begin_layout Plain Layout

set samples 200
\end_layout

\begin_layout Plain Layout

set zeroaxis
\end_layout

\begin_layout Plain Layout

set border 31 lw 1
\end_layout

\begin_layout Plain Layout

plot sin(pi*x)/(pi*x) lw 2 title "sinc(x)"
\end_layout

\begin_layout Plain Layout

\backslash
end{gnuplot}
\end_layout

\end_inset

\end_layout

\end_inset

\end_layout

\end_body
\end_document

Re: Can shell-escape take advantage of needauth framework?

On Mon, Jun 19, 2017 at 08:57:00PM +0200, Jürgen Spitzmüller wrote:

> Am Montag, den 19.06.2017, 20:33 +0200 schrieb Enrico Forestieri:
> > Because we don't know whether it's needed?
> 
> Why not? Can't we define that?

Are you able to tell that you need -shell-escape for the attached
document?

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?

2017-06-19 Thread Jürgen Spitzmüller

Am Montag, den 19.06.2017, 20:33 +0200 schrieb Enrico Forestieri:
> Because we don't know whether it's needed?

Why not? Can't we define that?

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Can shell-escape take advantage of needauth framework?

On Mon, Jun 19, 2017 at 07:54:03PM +0200, Jürgen Spitzmüller wrote:
> 
> Again: Why do we need the toolbar button? Why not let the document
> itself ask for shell-escaping, depending on the need for that (e.g.,
> minted)?

Because we don't know whether it's needed?

-- 
Enrico

Re: Can shell-escape take advantage of needauth framework?

2017-06-19 Thread Jürgen Spitzmüller

Am Montag, den 19.06.2017, 15:39 +0200 schrieb Enrico Forestieri:
> 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).

Again: Why do we need the toolbar button? Why not let the document
itself ask for shell-escaping, depending on the need for that (e.g.,
minted)?

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Can shell-escape take advantage of needauth framework?