Re: Living with shell-escape: Using two LyX instances - critique invited
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
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
On 27 July 2017 at 18:05, Tommaso Cucinottawrote: > 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
[ 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
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
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
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 MMwrote: 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
Bah, I again e-mailed only Guillaume and not the list. On 19 July 2017 at 00:00, Guillaume MMwrote: > > > 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
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
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
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.