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

2017-07-28 Thread Tommaso Cucinotta

On 28/07/2017 23:17, Tommaso Cucinotta wrote:

Actually, I have to check how the above "-x lyxrc-apply " behaves w.r.t. 
options not mentioned, e.g., whether reset to the default, or it does what one might be 
tempted to imagine, i.e., just override the mentioned options, leaving others as from 
prefs file.


just verified that the behavior seems the one you'd imagine, i.e.:
1) "Format..." is just one of the many prefs recognized tags, it can be omitted 
without problems
2) without recurring to weirdnesses of the Linux shell that allows to send a command 
options including "\n", one can simply use the -x option multiple times and 
specify the pref options to modify; I've modified the section accordingly, in 
http://wiki.lyx.org/Devel/SafetyAndSecurity#sDevel.SafetyAndSecurity_11

It's a bit long to write -x "lyxrc_appy \\option value", but the option is 
there nonetheless, so there's no need for another -Doption=value syntax.

T.


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

2017-07-28 Thread Tommaso Cucinotta

On 27/07/2017 23:08, Christian Ridderström wrote:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden true'

This is lyx-unsafe:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden false
\use_converter_needauth false'


I haven't added this to the wiki page as I don't understand the 'Format 22' 
part.

Perhaps you could explain it, or add it to the page?

Would this be applied after LyX preferences/config has been read, but before a 
document is opened?


couldn't study this for long, I just noticed that, when you click the Apply button from 
the Prefs dialog, we trigger the LYXRC_APPLY LFUN, and we pass as argument a string being 
an exact copy of a whole preferences file, including the first line "Format 
22", carriage returns, backslashes, and even comments #... :-). I assume the Format 
line is useful to allow for format upgrade(s) when starting a new version of LyX with a 
~/.lyx/preferences file written by an older version.
Actually, I have to check how the above "-x lyxrc-apply " behaves w.r.t. 
options not mentioned, e.g., whether reset to the default, or it does what one might be 
tempted to imagine, i.e., just override the mentioned options, leaving others as from 
prefs file.

T.


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

2017-07-27 Thread Christian Ridderström
On 27 July 2017 at 18:05, Tommaso Cucinotta  wrote:

> On 27/07/2017 17:31, Tommaso Cucinotta wrote:
>
>> I think what we might do in a relatively easy and generic way, is to allow
>> for setting individual preferences settings from the command-line, e.g.:
>>
>>alias lyx-safe='/usr/bin/lyx -Duse_converter_needauth_forbidden=true'
>>alias lyx-unsafe='/usr/bin/lyx -Duse_converter_needauth_forbidden=false
>> -Duse_converter_needauth=false'
>>
>> that would override whatever one has in the ~/.lyx/preferences config.
>>
>
I added a section to the wiki page to note that alias + options might be a
way.


>
> we have an already existing way through the LYXRC_APPLY LFUN, with a
> relatively heavy syntax:
>
> This is lyx-safe:
>
> ./src/lyx -x 'lyxrc-apply Format 22
> \use_converter_needauth_forbidden true'
>
> This is lyx-unsafe:
>
> ./src/lyx -x 'lyxrc-apply Format 22
> \use_converter_needauth_forbidden false
> \use_converter_needauth false'
>

I haven't added this to the wiki page as I don't understand the 'Format 22'
part.

Perhaps you could explain it, or add it to the page?

Would this be applied after LyX preferences/config has been read, but
before a document is opened?

/Christian


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

2017-07-27 Thread Tommaso Cucinotta

[ adding chr@, gm@ explicitly ]

On 27/07/2017 17:31, Tommaso Cucinotta wrote:

I think what we might do in a relatively easy and generic way, is to allow
for setting individual preferences settings from the command-line, e.g.:

   alias lyx-safe='/usr/bin/lyx -Duse_converter_needauth_forbidden=true'
   alias lyx-unsafe='/usr/bin/lyx -Duse_converter_needauth_forbidden=false 
-Duse_converter_needauth=false'

that would override whatever one has in the ~/.lyx/preferences config.


we have an already existing way through the LYXRC_APPLY LFUN, with a relatively 
heavy syntax:

This is lyx-safe:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden true'

This is lyx-unsafe:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden false
\use_converter_needauth false'

T.


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

2017-07-27 Thread Tommaso Cucinotta

On 27/07/2017 17:31, Tommaso Cucinotta wrote:

I think what we might do in a relatively easy and generic way, is to allow
for setting individual preferences settings from the command-line, e.g.:

   alias lyx-safe='/usr/bin/lyx -Duse_converter_needauth_forbidden=true'
   alias lyx-unsafe='/usr/bin/lyx -Duse_converter_needauth_forbidden=false 
-Duse_converter_needauth=false'

that would override whatever one has in the ~/.lyx/preferences config.


we have an already existing way through the LYXRC_APPLY LFUN, with a relatively 
heavy syntax:

This is lyx-safe:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden true'

This is lyx-unsafe:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden false
\use_converter_needauth false'

T.


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

2017-07-27 Thread Tommaso Cucinotta

On 27/07/2017 16:10, Guillaume MM wrote:

It makes sense that an option in the command line could disable needauth
entirely. It is becoming hard to track all the suggestions so if you are
interested in this I suggest filing enhancement reports / the wiki page.


I think what we might do in a relatively easy and generic way, is to allow
for setting individual preferences settings from the command-line, e.g.:

  alias lyx-safe='/usr/bin/lyx -Duse_converter_needauth_forbidden=true'
  alias lyx-unsafe='/usr/bin/lyx -Duse_converter_needauth_forbidden=false 
-Duse_converter_needauth=false'

that would override whatever one has in the ~/.lyx/preferences config.

This might be useful beyond needauth et al.

Bye,

T.


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

2017-07-27 Thread Guillaume MM

Le 23/07/2017 à 20:45, Christian Ridderström a écrit :

Bah, I again e-mailed only Guillaume and not the list.

On 19 July 2017 at 00:00, Guillaume MM  wrote:



I find that it would be more cumbersome and error-prone than a good
needauth implementation.



cumbersome:
Do you refer to using two user dirs, or perhaps having to (once?)
modify the parameter of the converter settings?
Or do you mean having two LyX windows open at the same time?


All of that. Also that, when running in unsafe mode, you have to assume
that everything is unsafe. So this unsafe mode it is still less safe
than a good needauth implementation.



error-prone:
Do you mean that you'll open the doc^H^H^Hprogram [*] in normal mode
and when you try to build it fails?
Or do you think it'd be difficult to set this thing up?


That one.



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



Yes, visibility that I'm operating in an unusual/non-default and
potentially dangerous mode.

Revokability I'd rather say isolation/separation.


By isolation/separation, what do you mean? Is it different from 
visibility (being able to tell whether things are safe)?




Besides wanting to allow the use of shell-escape only for a limited
set of documents (i.e. documents), I would likely also only want to
allow shell-escape when I want to run the program.


It makes sense that an option in the command line could disable needauth
entirely. It is becoming hard to track all the suggestions so if you are
interested in this I suggest filing enhancement reports / the wiki page.



Anyway, I think we should strive to allow a design where shell-escape
is not needed. And this topic is about a fallback when shell-escape is
necessary.


+1



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

2017-07-23 Thread Christian Ridderström
Bah, I again e-mailed only Guillaume and not the list.

On 19 July 2017 at 00:00, Guillaume MM  wrote:
>
>
> I find that it would be more cumbersome and error-prone than a good
> needauth implementation.


cumbersome:
Do you refer to using two user dirs, or perhaps having to (once?)
modify the parameter of the converter settings?
Or do you mean having two LyX windows open at the same time?

error-prone:
Do you mean that you'll open the doc^H^H^Hprogram [*] in normal mode
and when you try to build it fails?
Or do you think it'd be difficult to set this thing up?

Perhaps it's an important aspect that we're talking about a scenario
where the user is executing code embedded in his document, thus
essentially using LyX as an IDE to develop and execute programs.

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


Yes, visibility that I'm operating in an unusual/non-default and
potentially dangerous mode.

Revokability I'd rather say isolation/separation.

Besides wanting to allow the use of shell-escape only for a limited
set of documents (i.e. documents), I would likely also only want to
allow shell-escape when I want to run the program.  If I only need to
review/edit the program, e.g. after having received it (or had it
returned after modification) from an external source.

By only opening the unsafe LyX when I have to, I would know that
everything else I do in normal LyX is safe.  So I would only have to
be "careful" when using unsage-LyX.

Anyway, I think we should strive to allow a design where shell-escape
is not needed. And this topic is about a fallback when shell-escape is
necessary.

Guenter also wrote:
> If I got Christian right, the suggestion was intended as
>  stop-gap measure for power-users of LyX <= 2.2.x (as is my alternative 
> proposal).

Yes, it's a stop-gap measure. Depending on what happens for LyX >= 2.3
it might also be useful in the future.


/Christian

[*] They way converters are used here, the LyX document contains the
source code of something that can be executed. So it might help to
think of it as something containing source that we execute when
building (or previewing) the document. Thinking of it as running a
program might also help you think more about side effects of building
the document.   It also makes me think of providing better visibility
into exactly what code you are running, and perhaps if there could be
a way to "sign" versions of the code in the document then trust the
code when it's still signed.


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

2017-07-19 Thread Guenter Milde
On 2017-07-18, Guillaume MM wrote:
> Le 18/07/2017 à 21:29, Christian Ridderström a écrit :

>> If I had to use a converter that requires e.g. shell-escape perhaps the 
>> approach below would be useful. [...]

...

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

Agreed. I am glad to see this consensus emerging.

If I got Christian right, the suggestion was intended as stop-gap measure
for power-users of LyX <= 2.2.x (as is my alternative proposal).

Günter



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

2017-07-18 Thread 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



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

2017-07-18 Thread 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.