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

[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?)

[Christian Ridderström]

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: [LyX/master] Overtake layout translations from fi.po, ja.po, zh_CN.po

[Jari-Matti Mäkelä]

 Fri, 09 Jun 2017 20:30:07 +0200
Kornel Benko  wrote:

> At least 'make translations1' works. No, I did not so far. The changes
> are because of the fi.po.patch from Jari-Matti Mäkelä.
> Again, he should be asked if the new translation are OK for pdf.
> But, as I see it, I would not touch lib/layouttranslations in the fi
> part ATM. There are still about 2600 untranslated/fuzzy messages in
> fi.po. Jari-Mati seems to be willing to work on this if he finds some
> time.
> 
> Jari, what about the following in lib/layouttranslations?
> 
> -   "List of Algorithms" "Algoritmien luettelo"
> -   "List of Charts" "Kaavioiden luettelo"
> -   "List of Graphs[[mathematical]]" "Kuvaajien luettelo"
> -   "List of Schemes" "Kuvausten luettelo"
> -   "List of Tableaux" "Taulujen luettelo"
> +   "List of Algorithms" "Algoritmit"
> +   "List of Charts" "Kaaviot"
> +   "List of Graphs[[mathematical]]" "Kaaviot"
> +   "List of Schemes" "Kuvaukset"
> +   "List of Tableaux" "Taulut"qgit show
> 
> The following is wrong (according to Jari, maybe also wrong in fi.po)
> -   "Listing" "Ohjelmalistaus"
> +   "Listing" "Listaus"
> 

Sorry, only had time now to study this further.


Here are the correct translations.
 
"List of Algorithms"

-> Algoritmit


"List of Charts"

-> Kaaviot


"List of Graphs[[mathematical]]"

I have to admit I didn't understand the difference between charts and
graphs and couldn't find this yet from the GUI. Chart is e.g. a bar/pie
chart? Graph is some other graphical notation for expressing data? This
is confusing without knowing the context. If there is no other
difference, the same translation works:

-> Kaaviot


"List of Schemes"

Apparently this is related to chemistry? Is the 'scheme' like 'Chemical
equation', 'structural formula' or something else? It's hard to
translate this without knowing the context.


"List of Tableaux"

-> Taulukot

Tableaux is just a synonym for tables in french/latin? I tried to google
this but couldn't find any special meaning in LaTeX/LyX other than the
plural form of 'table'.


"Listing"
"Program Listing"

-> Ohjelmalistaus

Basically all 'listings' in LyX use the lstlisting package? From a
translators POV, it's really hard to identify the context, whether we
are listing some generic items or program code.


"List of Listings"
"List of Program Listing"

-> Ohjelmalistaukset


 - Jari-Matti

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

[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: Options for resolving the minted + shell-escape issue

[Richard Heck]

On 07/18/2017 09:56 AM, Jürgen Spitzmüller wrote:
> Am Dienstag, den 18.07.2017, 15:39 +0200 schrieb Jean-Marc Lasgouttes:
>> Whi, not, maybe along with the names of the converters (features) 
>> Sweave/gnuplot/minted present in current document and accepted by the
>> user.
> I would add a verbose tooltip when hovering the icon, something like
>
> '''
> NOTE: Shell escape access granted.
>
> For this document, access to the -shell-escape feature has been granted
> for the following converters: ...
>
> Note that this is a potential security risk. Use only if you trust the
> source of this document. Please refer to sec. xx of the User Guide for
> details.
>
> To withdraw shell escape access, press this icon.
> '''

This seems a reasonable solution to me. It is not perfect, but nothing is.

As I see it, the issue is that there are actually a wide variety of
reasons that users might want to
enable -shell-escape for various converters. As LyX currently functions,
the only way to do this
is to add this to the converter itself. This is dangerous from our point
of view NOT so much (or
only) because it is intrinsically dangerous, but rather because it it is
the kind of thing that is too
easy to "do and forget". Or, to put it differently: It is a serious
hassle to enable -shell-escape as
things are, and that invites people to do it and leave it. And that
really is a security risk.

The needauth mechanism provides some protection, but it seems to
introduce its own risks.

The current proposal is very much addressed to that problem, and I think
something like it should
be workable. But I'd make one more suggestion: Every time a user opens a
document for which this
sort of  thing will be enabled, we pop a warning before we do anything.
I.e., we do NOT just run
gnuplot in the background, but we say something like what Jürgen had
above, with buttons offering
either to proceed or not. Doing this once per document per session does
not seem too much to ask.
(It would streamline things a bit, too, if we could 'inherit' this
setting for child documents. So you
would not have to keep clicking through if there were a lot of children.)

Richard

Re: Living with shell-escape: Using two LyX instances - critique invited

[Guillaume MM]

Le 18/07/2017 à 21:29, Christian Ridderström a écrit :

Hi,

If I had to use a converter that requires e.g. shell-escape perhaps the 
approach below would be useful. What problems do you see with it?


1) Use two lyx user directories, one standard and one "dangerous", with 
converters using shell-escape only in the dangerous lyx.


2) Create a tiny shell script or a desktop icon etc to launch 
"dangerous" lyx using the "dangerous" user dir.


3) Configure dangerous lyx to have a reddish background colour.

4) By default work in the regular lyx and only use the dangerous lyx
 for documents where converters are needed.

Justification:
The 1) allows me to have converters permanently configured in a 
dangerous mode, and through 4) I select in which mode I work. The 4) 
also reduces risk exposure as I should not open documents from strangers 
in the dangerous lyx.


The 2) makes it easy for me to launch the dangerous lyx. I've actually 
used this approach for a requirements tool, to open it in a special mode.


The 3) makes it clear to me in which LyX I'm working.

By working as per above I'm reducing exposure and don't have to worry 
about shell-escape in normal documents.


What would the drawbacks be with this approach?
/Christian



I find that it would be more cumbersome and error-prone than a good
needauth implementation. If I understand, what you want is visibility
and revokability, which people already seem to agree are desirable
improvements to make to needauth (a red status bar thingy).

Guillaume

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

[Jean-Marc Lasgouttes]

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?

[Christian Ridderström]

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: Living with shell-escape: use a separate converter

[Guenter Milde]

On 2017-07-18, Christian Ridderström wrote:

> If I had to use a converter that requires e.g. shell-escape perhaps the
> approach below would be useful. What problems do you see with it?

> 1) Use two lyx user directories, one standard and one "dangerous", with
> converters using shell-escape only in the dangerous lyx.

> 2) Create a tiny shell script or a desktop icon etc to launch "dangerous"
> lyx using the "dangerous" user dir.

> 3) Configure dangerous lyx to have a reddish background colour.

> 4) By default work in the regular lyx and only use the dangerous lyx
> for documents where converters are needed.

As an alternative, you could define a separate converter for "insecure
latex":

1) Under Tools>Preferences>File Handling>File Formats define
   a new format, e.g. "PDF (pdflatex with shell escape)"

2) Under Tools>Preferences>File Handling>Converters define
   a converter from LaTeX (pdflatex) to the new format.
   
3) Use this new converter via the toolbar or menu for files requiring
   write18 shell access.

> Justification:
> The 1) allows me to have converters permanently configured in a dangerous
> mode, and through 4) I select in which mode I work. The 4) also reduces
> risk exposure as I should not open documents from strangers in the
> dangerous lyx.

There is one possible drawback in the alternative: if an attacker knows
about my converter and its name, he/she may set it as default format in the
document. Therefore, I don't propose this a workaround to ship with LyX.

> The 2) makes it easy for me to launch the dangerous lyx. I've actually used
> this approach for a requirements tool, to open it in a special mode.

The separate converter 

* bypasses the need for an extra directory and script, and
* allows to postpone the decision whether shell escape should be allowed
  until the very view/export action.

> The 3) makes it clear to me in which LyX I'm working.

In the alternative, selecting a non-default export/view format instead of
the simple default is a constant reminder of the added risk.
Alternatively, in a secure environment documents requiring write18 may
set the default format accordingly.

> By working as per above I'm reducing exposure and don't have to worry about
> shell-escape in normal documents.

ditto.

> PS. Documentation wise, I don't think it'd be that difficult to explain how
> it's done.

I don't think we should document this on a very prominent place. Instead,
these approaches could be recommended as more secure alternatives at places
suggesting to add shell-escape unconditionally.

Günter

[macOS] Behaviour when using an absolute path when doing save as

[Christian Ridderström]

Hi,

I just noticed a minor thing, and perhaps fully due to Qt and/or macOS.

Steps to reproduce:
- Start new document
- Place '/tmp/test.lyx' into your copy buffer
- Press 'Save' (Cmd-S)
- Paste filename from copy buffer, i.e. /tmp/test.lyx

Expected result:
I expected the file to be saved as /tmp/test.lyx

Discrepancy:
File was stored as :tmp:test.lyx under ~/Documents/.

Is this the expected behaviour?
/Christian

PS.
I did notice that if I type a '/' in the save dialog I get a dialog to
change folder. So this problem happened to me because I pasted in a path.

Errors with vref on de/Additional.lyx with lualatex

[Kornel Benko]

Hi,
apart from the missing glyphs errors at using \textcompwordmark
(which I 'solved' by using
\renewcommand{\textcompwordmark}{\vphantom{}}
in preamble)
there is also error with the system font 'FreeSerif,FreeSans,FreeMono'
when exporting to PDF(luatex)

 !Package varioref Error: \vref at page boundary 14-15 (may loop).

See the varioref package documentation for explanation.
Type  H   for immediate help.
 ...  
  
l.810 ...t\ \vref{Literaturverzeichnisse-mit-BibTeX}
  
Please check the pages in question. You might need to replace the \vref
or \vpageref by a normal \(page)ref to stop LaTeX running forever.

Changing the font to say Dejavu, the error disappears. Also inserting a line
for instance before paragraph 3.1.2 cures the compilation.


1.) Should we do anything here? Or is the user on its own if he/she gets such a 
message?

2.) Can we replace outputting \textcompwordmark with \vphantom{} in exported 
tex file?
  I could not see any difference in the pdflatex output. Also lualatex and 
xelatex displayed
  correctly. Moreover, using \textcompwordmark with xelatex displays wrong.

Kornel

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

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Tue, Jul 18, 2017 at 05:03:52PM +0200, Pavel Sanda wrote:
> 
> After reading all the thread now, would you call the position below
> hypocritical?
> 
> 1. I do not like needauth mechanism much, but I don't see better way how to
>allow advanced users to work with knitr/gnuplot without too much hassle.

Note that users can define their own dangerous converters and cannot be
stopped from doing that. The issue is that these converters are offered
by LyX itself. People can copy the converters from 2.2 without too much
hassle. The hypocrisy I was referring to is wanting to justify the
presence of such dangerous converters and at the same time asking to
revert a feature which is not insecure by itself.

> 2. We want minted support. New implementation does not work out of the box,
>and if we want it working & secure we need extend needauth more broadly
>into the code.

I have to disagree. It works out of the box and the user has only to know
what to do for using it. This is not a problem nowadays, because you can
use google to find web pages that explain in detail and with images what
has to be done. With the support offered by LyX it is simply not necessary
anymore using ERT. So, I don't see why this can be a problem.

>If there was no other way, it would be indeed unfair to use needauth
>unilateraly (that's your 'hypocrisy' argument if I get it right), but there
>seems to be pretty good chance that minted maintainer will solve the issue
>within couple months, which gives two other possible ways for ppl uneasy
>with needauth:
>a) return back to 2.2 behaviour and wait until maintainer of minted
>   let us call pygments directly and introduce it in the next cycle.
>b) have minted & needauth, but drop it once we can (and I would propose
>   the same thing for knitr/gnuplot if it ever becomes possible).
> 
> I can't read other people minds to speculate about their inner intensions,
> but to feel uneasiness about needauth-machinery creepism into the code
> seems valid reasoning from my perspective.

Now I don't care anymore. Do whatever you want.

-- 
Enrico

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

[Jean-Marc Lasgouttes]

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?

[Christian Ridderström]

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

Living with shell-escape: Using two LyX instances - critique invited

[Christian Ridderström]

Hi,

If I had to use a converter that requires e.g. shell-escape perhaps the
approach below would be useful. What problems do you see with it?

1) Use two lyx user directories, one standard and one "dangerous", with
converters using shell-escape only in the dangerous lyx.

2) Create a tiny shell script or a desktop icon etc to launch "dangerous"
lyx using the "dangerous" user dir.

3) Configure dangerous lyx to have a reddish background colour.

4) By default work in the regular lyx and only use the dangerous lyx
for documents where converters are needed.

Justification:
The 1) allows me to have converters permanently configured in a dangerous
mode, and through 4) I select in which mode I work. The 4) also reduces
risk exposure as I should not open documents from strangers in the
dangerous lyx.

The 2) makes it easy for me to launch the dangerous lyx. I've actually used
this approach for a requirements tool, to open it in a special mode.

The 3) makes it clear to me in which LyX I'm working.

By working as per above I'm reducing exposure and don't have to worry about
shell-escape in normal documents.

What would the drawbacks be with this approach?
/Christian

PS. Documentation wise, I don't think it'd be that difficult to explain how
it's done.

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

[Jean-Marc Lasgouttes]

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?

[Christian Ridderström]

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: [LyX/master] Add some notes on forward/reverse search with evince.

[Jürgen Spitzmüller]

Am Dienstag, den 18.07.2017, 09:31 +0200 schrieb Jürgen Spitzmüller:
> No copyright issues. The scripts are GPL-licensed. And they are
> > written
> > in Python ;-)
> 
> Except for one (a bash script). But it would be easy to rewrite this
> one in python as well.

I've done a (rough) conversion of the bash script to python and
committed the three scripts to 3rdparty/evince_sync.

I would appreciate if someone could check and improve the python code.
It works for me, but I am sure it is rather ugly.

Jürgen

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

Re: Options for resolving the minted + shell-escape issue

[Pavel Sanda]

Pavel Sanda wrote:
>b) have minted & needauth, but drop it once we can (and I would propose

.. by "it" I mean needauth ..

> 
> Pavel

Re: Options for resolving the minted + shell-escape issue

[Pavel Sanda]

Enrico Forestieri wrote:
> On Tue, Jul 18, 2017 at 01:28:38PM +0200, Pavel Sanda wrote:
> > Enrico Forestieri wrote:
> > > On Tue, Jul 18, 2017 at 12:57:24PM +0200, Kornel Benko wrote:
> > > > you have good and valid arguments. But don't you see how insulting some 
> > > > of
> > > > your mails are?
> > > 
> > > No, I actually don't. And I apologize if it may seem so.
> > 
> > It unfortunately seems so :(
> 
> Please, pay attention to not confusing hypocrisy and frankness.

After reading all the thread now, would you call the position below 
hypocritical?

1. I do not like needauth mechanism much, but I don't see better way how to
   allow advanced users to work with knitr/gnuplot without too much hassle.
   
2. We want minted support. New implementation does not work out of the box,
   and if we want it working & secure we need extend needauth more broadly
   into the code.
   
   If there was no other way, it would be indeed unfair to use needauth
   unilateraly (that's your 'hypocrisy' argument if I get it right), but there
   seems to be pretty good chance that minted maintainer will solve the issue
   within couple months, which gives two other possible ways for ppl uneasy
   with needauth:
   a) return back to 2.2 behaviour and wait until maintainer of minted
  let us call pygments directly and introduce it in the next cycle.
   b) have minted & needauth, but drop it once we can (and I would propose
  the same thing for knitr/gnuplot if it ever becomes possible).

I can't read other people minds to speculate about their inner intensions,
but to feel uneasiness about needauth-machinery creepism into the code
seems valid reasoning from my perspective.

Pavel

Re: Options for resolving the minted + shell-escape issue

[Jürgen Spitzmüller]

Am Dienstag, den 18.07.2017, 15:39 +0200 schrieb Jean-Marc Lasgouttes:
> Whi, not, maybe along with the names of the converters (features) 
> Sweave/gnuplot/minted present in current document and accepted by the
> user.

I would add a verbose tooltip when hovering the icon, something like

'''
NOTE: Shell escape access granted.

For this document, access to the -shell-escape feature has been granted
for the following converters: ...

Note that this is a potential security risk. Use only if you trust the
source of this document. Please refer to sec. xx of the User Guide for
details.

To withdraw shell escape access, press this icon.
'''

Jürgen

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

Re: Options for resolving the minted + shell-escape issue

[Jean-Marc Lasgouttes]

Le 18/07/2017 à 15:35, Jürgen Spitzmüller a écrit :

https://commons.wikimedia.org/wiki/Tango_icons#/media/File:Emblem-impor
tant-red.svg


Whi, not, maybe along with the names of the converters (features) 
Sweave/gnuplot/minted present in current document and accepted by the user.


JMarc

Re: Options for resolving the minted + shell-escape issue

[Jürgen Spitzmüller]

Am Dienstag, den 18.07.2017, 14:58 +0200 schrieb Jean-Marc Lasgouttes:
> As I wrote elsewhere, I am for this solution in the status bar, as
> long 
> as it is really visible (I was about to propose a blinking red box,
> but 
> that would be a bit too cheesy).

Something such as this would do IMHO:
https://commons.wikimedia.org/wiki/Tango_icons#/media/File:Emblem-impor
tant-red.svg

Jürgen

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

Re: Options for resolving the minted + shell-escape issue

[Jean-Marc Lasgouttes]

Le 18/07/2017 à 14:26, Jürgen Spitzmüller a écrit :

Am Montag, den 17.07.2017, 15:18 +0200 schrieb Enrico Forestieri:

I think the most effective was the one that allowed to
add -shell-escape to selected documents with the possibility of
revoking
this permission. There was an icon indicating this fact and clicking
it
one could revoke those rights.

This was a reasonable alternative, IMO, not specifically tied to
minted,


Just for the records, I agree here (although I would prefer to have
this icon in the status bar, and only show up if shell-escape is opted
in, which would also be more salient).


As I wrote elsewhere, I am for this solution in the status bar, as long 
as it is really visible (I was about to propose a blinking red box, but 
that would be a bit too cheesy).


JMarc

Re: Options for resolving the minted + shell-escape issue

[Jürgen Spitzmüller]

Am Montag, den 17.07.2017, 15:18 +0200 schrieb Enrico Forestieri:
> I think the most effective was the one that allowed to
> add -shell-escape to selected documents with the possibility of
> revoking
> this permission. There was an icon indicating this fact and clicking
> it
> one could revoke those rights.
> 
> This was a reasonable alternative, IMO, not specifically tied to
> minted,

Just for the records, I agree here (although I would prefer to have
this icon in the status bar, and only show up if shell-escape is opted
in, which would also be more salient).

Other than that, I don't have to contribute anything new to this
debate.

Jürgen

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

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Tue, Jul 18, 2017 at 01:28:38PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Tue, Jul 18, 2017 at 12:57:24PM +0200, Kornel Benko wrote:
> > > you have good and valid arguments. But don't you see how insulting some of
> > > your mails are?
> > 
> > No, I actually don't. And I apologize if it may seem so.
> 
> It unfortunately seems so :(

Please, pay attention to not confusing hypocrisy and frankness.

-- 
Enrico

Re: Options for resolving the minted + shell-escape issue

[Pavel Sanda]

Enrico Forestieri wrote:
> On Tue, Jul 18, 2017 at 12:57:24PM +0200, Kornel Benko wrote:
> > you have good and valid arguments. But don't you see how insulting some of
> > your mails are?
> 
> No, I actually don't. And I apologize if it may seem so.

It unfortunately seems so :(
Pavel

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Tue, Jul 18, 2017 at 12:57:24PM +0200, Kornel Benko wrote:
> 
> Dear Enrico,
> you have good and valid arguments. But don't you see how insulting some of
> your mails are?

No, I actually don't. And I apologize if it may seem so.

-- 
Enrico

Re: Options for resolving the minted + shell-escape issue

[Kornel Benko]

Am Dienstag, 18. Juli 2017 um 12:01:19, schrieb Enrico Forestieri 

> > (About the personal attacks: I mean to write about it at a later point
> > in time. If I have not been replying to Enrico, this does not mean that
> > I do not see his messages.)
> 
> Dear Guillame,
> 
> you can try again to muddy waters, speak of personal attacks trying
> to reverse what is actually happening, but the reality is that you
> are willing to apply double standards to issues that are exactly the
> same. You cannot say you are doing it because you are concerned about
> security, otherwise you would have said the same for the needauth
> feature. You didn't do that and now you want to treat differently the
> shell-escape thing (to which I am not interested), but you are also
> intriguing to remove a feature that has no impact on security
> per se. Everyone can wonder why and arrive at some conclusion.

Dear Enrico,
you have good and valid arguments. But don't you see how insulting some of your 
mails are?

We really should restart the Friday tradition.

Kornel


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

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Tue, Jul 18, 2017 at 11:32:14AM +0200, Guillaume MM wrote:
> Le 17/07/2017 à 16:25, Richard Heck a écrit :
> > 
> > If I read JMarc's messages properly, then he also agrees that the
> > security issues are essentially the same. That also seems right to me.
> 
> Hi Richard,
> 
> 
> I did not reply to Jean-Marc, so I'll say here that I too agree with
> what he wrote at
> . I
> think we are on the same page that -shell-escape and R are similar in
> terms of security and should both be treated using needauth, and
> needauth be improved, you can also find suggestions along those lines in
> earlier messages of mine.
> 
> > 
> > It's true that we've always tried to be cautious about security.
> 
> I saw that you have been a proponent of the safe approach in
> the past and thank you for this.
> 
> > But
> > there is only so much we can do. Warning the user that they are about to
> > do something that is potentially dangerous, and making it as simple as
> > possible for the user to manage those privileges, is the best we can do.
> > I don't see the difference either between R-code and minted in this
> > respect. So I'm inclined to go with some version of Enrico's patch.
> > 
> 
> I disagree with the "there is only so much we can do" argument.
> Minted.sty is only a small interface to Pygments.
> 
> * One could implement one of the several other interfaces to Pygments
> (trading a few features in exchange of security).
> 
> * One could interface Pygments directly with LyX without relying on a
> LaTeX package.
> 
> * One could ask the author of minted.sty whether he would like to
> provide an alternative to requiring -shell-escape.
> 
> Either of these would require less time and less imagination than has
> been spent so far into personal attacks. The limitations of
> needauth-like mechanisms have been raised early, and ignored.
> 
> One cannot do much currently to increase the security of users of
> -shell-escape, R or gnuplot. Needauth only helps when these are not
> needed. But one can try to avoid encouraging LyX users becoming
> -shell-escape users. That would be a real service made to LyX users.
> 
> I see arbitrary code execution at the other end of balance and think
> that "there is only so much we can do" means a complete turnaround in
> this case.
> 
> Guillaume
> 
> 
> (About the personal attacks: I mean to write about it at a later point
> in time. If I have not been replying to Enrico, this does not mean that
> I do not see his messages.)

Dear Guillame,

you can try again to muddy waters, speak of personal attacks trying
to reverse what is actually happening, but the reality is that you
are willing to apply double standards to issues that are exactly the
same. You cannot say you are doing it because you are concerned about
security, otherwise you would have said the same for the needauth
feature. You didn't do that and now you want to treat differently the
shell-escape thing (to which I am not interested), but you are also
intriguing to remove a feature that has no impact on security
per se. Everyone can wonder why and arrive at some conclusion.

-- 
Enrico

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

[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: Options for resolving the minted + shell-escape issue

[Guillaume MM]

Le 17/07/2017 à 16:25, Richard Heck a écrit :


If I read JMarc's messages properly, then he also agrees that the
security issues are essentially the same. That also seems right to me.


Hi Richard,


I did not reply to Jean-Marc, so I'll say here that I too agree with
what he wrote at
. I
think we are on the same page that -shell-escape and R are similar in
terms of security and should both be treated using needauth, and
needauth be improved, you can also find suggestions along those lines in
earlier messages of mine.



It's true that we've always tried to be cautious about security.


I saw that you have been a proponent of the safe approach in
the past and thank you for this.


But
there is only so much we can do. Warning the user that they are about to
do something that is potentially dangerous, and making it as simple as
possible for the user to manage those privileges, is the best we can do.
I don't see the difference either between R-code and minted in this
respect. So I'm inclined to go with some version of Enrico's patch.



I disagree with the "there is only so much we can do" argument.
Minted.sty is only a small interface to Pygments.

* One could implement one of the several other interfaces to Pygments
(trading a few features in exchange of security).

* One could interface Pygments directly with LyX without relying on a
LaTeX package.

* One could ask the author of minted.sty whether he would like to
provide an alternative to requiring -shell-escape.

Either of these would require less time and less imagination than has
been spent so far into personal attacks. The limitations of
needauth-like mechanisms have been raised early, and ignored.

One cannot do much currently to increase the security of users of
-shell-escape, R or gnuplot. Needauth only helps when these are not
needed. But one can try to avoid encouraging LyX users becoming
-shell-escape users. That would be a real service made to LyX users.

I see arbitrary code execution at the other end of balance and think
that "there is only so much we can do" means a complete turnaround in
this case.

Guillaume


(About the personal attacks: I mean to write about it at a later point
in time. If I have not been replying to Enrico, this does not mean that
I do not see his messages.)

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

[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?

[Jean-Marc Lasgouttes]

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?

[Jean-Marc Lasgouttes]

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: [LyX/master] Preferences shows current zoom instead of preference's default zoom (#10455)

[Scott Kostyshak]

On Sun, May 07, 2017 at 02:18:41PM +0200, Guillaume MM wrote:
> commit 4183a9f4dc9bc0893fc59cd7e31db9bc7e52eea9
> Author: Daniel Ramöller 
> Date:   Sat Oct 29 10:28:34 2016 +0200
> 
> Preferences shows current zoom instead of preference's default zoom 
> (#10455)
> 
> - Adds a currentZoom variable which holds the current zoom level.
> 
> - The zoom stored in preferences is used as default zoom level (default 
> binding:
>   M+0).
> 
> - The currentZoom is saved and restored via QSettings.
> 
> - Adds LFUN buffer-zoom for (re)setting zoom.

After this commit, I see the following:

$ lyx -dbg action

Debugging `action' (User commands)
frontends/qt4/GuiApplication.cpp (1576): cmd:  action: 269 [window-new]
arg: '' x: 0 y: 0
frontends/qt4/GuiApplication.cpp (1576): cmd:  action: 367 [buffer-zoom]
arg: '110' x: 0 y: 0
frontends/qt4/GuiApplication.cpp (1586): action buffer-zoom
[buffer-zoom] is disabled at this location
frontends/qt4/GuiApplication.cpp (1357): dispatch msg is Command not
allowed without any document open
frontends/qt4/GuiApplication.cpp (1357): dispatch msg is 


before, I saw this:


$ lyx -dbg action

Debugging `action' (User commands)
frontends/qt4/GuiApplication.cpp (1570): cmd:  action: 269 [window-new]
arg: '' x: 0 y: 0
frontends/qt4/GuiApplication.cpp (1351): dispatch msg is 

Scott


signature.asc
Description: PGP signature

Re: Different LaTeX output when exporting than when previewing

[Guenter Milde]

On 2017-07-03, Scott Kostyshak wrote:
> On Mon, Jul 03, 2017 at 03:02:31PM +0200, Jean-Marc Lasgouttes wrote:
>> Le 29/05/2017 à 18:06, Scott Kostyshak a écrit :
>> > If I do the above several times, I eventually get:
>> > 3c3
>> > <
>> > \documentclass[12pt,english,ngerman,spanish,bibliography=totoc,index=totoc,BCOR7.5mm,titlepage,captions=tableheading,dvipsnames,table]{scrbook}
>> > ---
>> > > \documentclass[12pt,ngerman,english,spanish,bibliography=totoc,index=totoc,BCOR7.5mm,titlepage,captions=tableheading,dvipsnames,table]{scrbook}
>> > --

>> Which document is it that eventually changes? This could be a uninitialized
>> variable.

> Not sure. I can spend some time looking into it, but I first wanted to
> make sure that at least one other person could reproduce before I start
> spending time on it.

While it may point to an underlying issue, the difference itself is
non-critical:

The export uses LuaTeX with 8-bit TeX fonts and the Babel language
package.

With Babel, the main document language must be given last, the
order of secondary languages does not matter, hence

  \documentclass[english,ngerman,spanish]{scrbook}

and

  \documentclass[ngerman,english,spanish]{scrbook}

produce identical output (unless there is some bug in Babel).

Günter

Re: Cleanup before 2.3.0?

[Guenter Milde]

On 2017-07-15, Christian Ridderström wrote:
> On 7 July 2017 at 04:37, Scott Kostyshak  wrote:

>> > What do others think?

>> ^ If you get support from other LyX devs, and you are willing to take
>> care of everything, then I'm fine with it. My only other criterion is
>> that I don't want to personally spend any time on this. We have other
>> issues and debates going on where I want to spend my time. So the hard
>> part is convincing other LyX devs.

I support a cleanup before 2.3.0.

> I'm willing to take care of it and have been busy demonstrating it's safe
> to use clang-format. The "simple" task of verifying that a binary based on
> reformatted code is identical took much longer than expected and turned out
> to be non-trivial. E.g., building LyX twice in a row from the same source
> and from the same location didn't result the same binary on my mac. 

The idea of "reproducible builds" https://reproducible-builds.org/
may be of help here.
It has docs on "how to make your software build reproducibly…"
https://reproducible-builds.org/docs/.

Günter

Re: [LyX/master] Add some notes on forward/reverse search with evince.

[Jürgen Spitzmüller]

Am Montag, den 17.07.2017, 19:35 +0200 schrieb Jürgen Spitzmüller:
> No copyright issues. The scripts are GPL-licensed. And they are
> written
> in Python ;-)

Except for one (a bash script). But it would be easy to rewrite this
one in python as well.

Jürgen

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

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

[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?

[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?

[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: Cleanup before 2.3.0?

[Scott Kostyshak]

On Mon, Jul 17, 2017 at 12:10:31AM +0200, Christian Ridderström wrote:

> I just went through a large chunk of the minted postings and I still don't
> have a clear idea about my preference, and I'm therefore not sure what to
> write that'd contribute.
> 
> I'm generally inclined towards security and backwards compatibility.

Well, the problem is that it's not completely clear (at least to me)
which way forward is more secure. It's not that we're only talking about
trading off security versus a feature.

> my baseline is that I'd
> really hate it if I wasn't able to compile documents I wrote a long time
> ago.

+1

> I'd better stop writing now.

:)

Re: Cleanup before 2.3.0?

[Scott Kostyshak]

On Mon, Jul 17, 2017 at 12:48:34AM +0200, Enrico Forestieri wrote:

> ATM, in no way you can risk
> something if you decide to use minted. You would have to know what to
> change in the preferences for taking that risk. On the contrary, when
> using one of the above mentioned features, the risk is at the tip of
> a mouse click.

+1

Scott

Re: Silent/automatic execution of converter and needauth, concrete questions to clarify my understanding

[Scott Kostyshak]

On Mon, Jul 17, 2017 at 11:53:38PM +0200, Christian Ridderström wrote:

> A) In LyX 2.2.x, if I open the document, no "converters" are executed. But
> when I attempt to generate the PDF, the document could via e.g. 'R' execute
> arbitrary code on my computer, as if it were my user account. And this
> would happen silently, with no warning etc.
> Correct?

Yes.

> But what would happen if I used LyX 2.3.0alphaX and tried to build the
> document?

Guillaume gave a more detailed answer. The quick answer is that with the
defaults of 2.3.0alpha1-1, you would be prompted before the R code was
run.

Scott

Re: Options for resolving the minted + shell-escape issue

[Scott Kostyshak]

On Sun, Jul 16, 2017 at 11:21:16PM +0200, Enrico Forestieri wrote:

> Look, some people doesn't want to use listings and prefer minted.
> External templates and modules for using minted have been proposed.
> Thus, minted is used and people know how to deal with it. Now they
> don't have to use ERT or strange tricks.

To me this is a strong argument. And further, the "strange tricks" can
lead to security issues (e.g. setting -shell-escape manually and
forgetting to remove it).

> So, what is the problem?

I think that some believe that by including code in LyX that requires
-shell-escape would lead to more users using -shell-escape which could
be viewed as less secure. Further, in the case of minted, shell-escape
might not be required in the future.

Re: [LyX/master] Update fr.po for beta

[Scott Kostyshak]

On Mon, Jul 17, 2017 at 03:19:56PM +0200, Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
> > Le 16/07/2017 ? 20:53, Scott Kostyshak a écrit :
> >> I don't have svn commit privileges. Also, I don't actually know how to
> >> use svn.
> >
> > Do you want svn privileges? Do you want to learn some y2k technology that 
> > is not needed anymore? ;)
> >
> > Seriously, it is less mind-damaging than git, but for this cheap price, you 
> > obtain less, of course.
> 
> Might be worth it, there's no way Scott can update web news for beta/RCs. P

Sure, I can try to do it. There is probably an old LyX Wiki page with
useful commands.

Scott