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

[Jean-Marc Lasgouttes]

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

except if I disable needauth globally :(


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


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


JMarc

Re: Errors with vref on de/Additional.lyx with lualatex

[Kornel Benko]

Am Freitag, 21. Juli 2017 um 22:08:48, schrieb Guenter Milde 

> On 2017-07-20, Kornel Benko wrote:
> > Am Mittwoch, 19. Juli 2017 um 22:23:32, schrieb Kornel Benko 
> > 
> >> Am Mittwoch, 19. Juli 2017 um 19:48:49, schrieb Guenter Milde 
> >> 
> >> > On 2017-07-19, Kornel Benko wrote:
> >> > 
> >> > > [-- Type: text/plain, Encoding: 7bit --]
> >> > 
> >> > > Am Mittwoch, 19. Juli 2017 um 15:00:16, schrieb Kornel Benko 
> >> > > 
> >> > >> So, maybe better we could omit \textcompwordmark in mono fonts.
> >> > 
> >> > > This patch works for me. It uses vphantom{}, but only between '<<' and 
> >> > > '>>'.
> >> > 
> >> > See my other post for alternatives solving the "missing character" error
> >> > with Unicode fonts for \textcompwordmark.
> 
> >> I have read it. I understand the usage and I don’t insist on removing
> >> textcompwordmark any longer.
> 
> >> I don't insist. I would insist on removing textcompwordmark in mono
> >> fonts, but did not see an easy way.
> 
> > It turned out, it is easy.
> 
> But it is still wrong: 
> 
> * It is LyX policy to keep LaTeX output stable (unless it turns out to be
>   wrong).
> 
> * \textcompwordmark is the correct LaTeX internal character
>   representation (LICR) for u200C (zero width non joiner, ZWNJ).

OK

>   If some fonts are missing this character this is a bug in the fonts or
>   in the code calling this missing character (here tu1enc.def in latex/base/).
>   
> * The workaround should fix the command, not use a different
>   one. Power users are then still able to override our workaround with
>   their own re-definition of \textcompwordmark.

Mark, that the change is done only for mono fonts.

> 
> * Actually, in the case of ZWNJ, just dropping the missing character results
>   in correct output. 
>   --> We don't even need to add a workaround, if we remove
> the "warning to error conversion for missing characters" for this case.
> 

Please not now. Who may do the work?

> 
> > Output for desired ligatures with the attached patch is:
> > "\\vphantom{}" if mono mono-fonts
> > "\\textcompwordmark " else.
> 
> This will only help for documents using DejaVu.  OTOH, it is not required
> for Free* and no help for LatinModern.
> 

No, DejaVu is selected because of endless latex loop, nothing to do with 
\\textcompwordmark

> 
> ...
> 
> > diff --git a/lib/doc/de/Additional.lyx b/lib/doc/de/Additional.lyx
> > index 5ccd07b..539aa6d 100644
> > --- a/lib/doc/de/Additional.lyx
> > +++ b/lib/doc/de/Additional.lyx
> > @@ -41,9 +41,9 @@ shapepar
> >  \language_package default
> >  \inputencoding auto
> >  \fontencoding global
> > -\font_roman "lmodern" "default"
> > -\font_sans "lmss" "default"
> > -\font_typewriter "lmtt" "default"
> > +\font_roman "lmodern" "DejaVu Serif [bitstream]"
> > +\font_sans "lmss" "DejaVu Sans [bitstream]"
> > +\font_typewriter "lmtt" "DejaVu Sans Mono [bitstream]"
> >  \font_math "auto" "auto"
> >  \font_default_family default
> >  \use_non_tex_fonts false
> 
> This fixes the test case but not the problem.

This fixes the lyx file which we provide.

> The correct fix is either an exception to the "error-on-missing-chars"
> feature, or providing the workaround (re-defining to the original default):
> 
>   % ZWNJ missing in many Unicode fonts:
>   \DeclareTextCommand{\textcompwordmark}{\UnicodeEncodingName}{%
>  \leavevmode\kern\z@}
> 
> in LaTeXFeatures.cpp and "require" it in case \textcompwordmark is used in
> documents with "non-TeX fonts" if configure detects TeXLive16 or later.
> 
> Günter

Kornel

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

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

[Guenter Milde]

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

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


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


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

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

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

a) adding a red icon to the status bar if a document has the "allow
   shell-escape" flag.
  
b) revoking the permission, if the document is moved/copied to another
   location.
  
I like the approach, especially b) seems a good compromise between user
comfort and security.

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

Some ideas:

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

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

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


Günter

Re: Errors with vref on de/Additional.lyx with lualatex

[Kornel Benko]

Am Freitag, 21. Juli 2017 um 21:30:35, schrieb Guenter Milde 

> On 2017-07-19, Kornel Benko wrote:
> 
> 
> 
> > I did as you proposed (Dejavu font), but maybe you are unaware that
> > With TL15 everything compiles here
> 
> TL15 does not bind \textcompwordmark to the ZWNJ character but uses the
> default definition also for Unicode fonts (EC1 and EC2).
> 
> > With TL16 I get missing glyphs if font is Dejavu, but not with Free*
> > Mark, that changing 'Dejavu Sans Mono' to e.g. 'Dejavu Sans' cures the 
> > compilation though
> > With TL17 I get missing glyphs for any font. I have to replace the mono 
> > font to
> > get it to compile.
> 
> In TL16, the font encoding used by "fontspec" (Xe/LuaTeX with "system
> fonts") changed to TU: 
> 
> * In this encoding, \textcompwordmark is mapped to the ZWNJ character.
> 
> * Only some fonts actually contain this character.
> 
> * LyX turns the "missing character" WARNING into an ERROR
>   This is usually a good thing (because printing characters that are missing
>   represent data loss).
>   
>   For ZWNJ, it would be better if the warning was *not*
>   turned into an error, because the ligature break works also if the
>   character is missing -- no data loss, correct output!
> 
> > So, maybe better we could omit \textcompwordmark in mono fonts.
> 
> This would only cure the special case tested in the export tests. It will
> not help in documents with the default LM or custom fonts where the serif
> or non-serif fonts miss the ZWNJ. 
> It would also not help in documents using the "ligature-break" special-char.
> 

But that is not our problem IMHO. If someone uses that glyph with a font not 
having it,
it is not lyx's or latex problem.
But for mono-fonts, who may expect the glyph to exist?
WE output \textcompwordmark also for mono fonts, and this feels very wrong.

> The better cure is one of
> 
> a) an exception list for the "turn missing character warning to error" code,
> 
> b) preamble code reverting the binding of \textcompwordmark to ZWNJ (at
>least for the next years until "system fonts" can be safely expected to
>ship with the ZWNJ character).
>
> I prefer a), because the missing character still breaks the ligature (i.e.
> the output looks as expected).

Hm, yes, but that would also be a change in command line for lyx.
ATM, lyx is responsible to filter the latex log if instructed so.
# lyx --ignore-error-message missing_glyphs
With this method (ATM) _any_ missing glyph is ignored unfortunately.

> Günter
> 
Kornel

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

Re: [LyX/master] Preferences shows current zoom instead of preference's default zoom (#10455)

[Scott Kostyshak]

On Tue, Jul 18, 2017 at 04:43:44AM -0400, Scott Kostyshak wrote:
> 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 

Racoon, I just wanted to make sure that you saw this email about the
above potential regression. Will you have time to look into it?

Scott


signature.asc
Description: PGP signature

Re: export tests for beamer with TL17

[Kornel Benko]

Am Freitag, 21. Juli 2017 um 21:08:48, schrieb Guenter Milde 

> On 2017-07-21, Kornel Benko wrote:
> 
> > OK, instead of \usepackage{fix-cm}
> > the entry \usepackage{lmodern}
> > works too. At least for pdflatex.
> 
> This also cures the use of dead ugly bitmapped EC fonts auto-substituted for
> the default CM because LyX sets the font encoding to T1!
> 
> Please change the example(s) to use Latin Modern fonts.
> Instead of inserting \usepackage{lmodern}, change the font settings
> (in the GUI or in the lyx sources).
> 
> Any current LaTeX distribution supporting "beamer" should also ship
> LModern fonts.
> 
> 
> Günter

Thanks, done. But don't know, how to handle Japanese documents.

Kornel

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

Re: Any descriptions of the security aspects (related to needauth and shell-escape)?

[Scott Kostyshak]

On Sat, Jul 22, 2017 at 12:22:21AM +0200, Enrico Forestieri wrote:

> > I think the above summaries by Richard and Guillaume are accurate.
> 
> Please, note that I did not even think about adding support for shell
> escape for the sake of minted. In my view, the minted support was ready
> as it is now.

Noted. I was the one that lead us into that discussion.

Scott


signature.asc
Description: PGP signature

Re: Any descriptions of the security aspects (related to needauth and shell-escape)?

[Enrico Forestieri]

On Fri, Jul 21, 2017 at 04:29:04PM -0400, Scott Kostyshak wrote:

> On Thu, Jul 20, 2017 at 07:04:56PM +0200, Guillaume MM wrote:
> > Le 19/07/2017 à 16:59, Richard Heck a écrit :
> > > On 07/19/2017 02:22 AM, Christian Ridderström wrote:
> > > > Hi,
> > > > 
> > > > When having tried to contribute to the discussion on needauth and
> > > > shell-escape I've felt that it's quite difficult to get a good picture
> > > > of things like:
> > > > - Goals of design, what are we trying to achieve
> > > > - Principle of design and system
> > > > - Assumed threat models, and perhaps list threat scenarios we _don't_
> > > > try to protect against
> > > > 
> > > > The e-mail threads are ... long, sometimes confusing and I suspect
> > > > contains at least a few misunderstandings.  So I would like to ask
> > > > (not being optimistic), if there's some design description anywhere?
> > > 
> > > No, as usual, there is not. The needauth mechanism was developed by
> > > Tommaso in response
> > > to security worries about certain sorts of converters, e.g., the ones
> > > for R and related worries
> > > about the use of gnuplot. (It may have been the latter that got him
> > > interested.) Once that was on
> > > board, Enrico decided to employ at least a somewhat similar mechanism to
> > > support minted.sty,
> > > and for whatever reason, that set off alarm bells which, in retrospect,
> > > should have gone off
> > > earlier. So we find ourselves in the middle of things.
> > > 
> > > Richard
> > > 
> > > 
> > 
> > Yes Richard, (smaller) alarm bells could have gone off a month earlier
> > if I had paid attention to the gnuplot discussion. They went off when
> > Scott explicitly asked about extending the use of needauth, and it did
> > not seem to have changed the course of things.
> > 
> > For 2.3 Scott chose to ask "what can we do for LyX to be the safest?"
> > rather than the obvious solution to get beta out. I find it reasonable
> > and a worthwhile time investment.
> 
> I think the above summaries by Richard and Guillaume are accurate.

Please, note that I did not even think about adding support for shell
escape for the sake of minted. In my view, the minted support was ready
as it is now.

-- 
Enrico

Re: Errors with vref on de/Additional.lyx with lualatex

[Guenter Milde]

On 2017-07-20, Kornel Benko wrote:
> Am Mittwoch, 19. Juli 2017 um 22:23:32, schrieb Kornel Benko 
>> Am Mittwoch, 19. Juli 2017 um 19:48:49, schrieb Guenter Milde 
>> 
>> > On 2017-07-19, Kornel Benko wrote:
>> > 
>> > > [-- Type: text/plain, Encoding: 7bit --]
>> > 
>> > > Am Mittwoch, 19. Juli 2017 um 15:00:16, schrieb Kornel Benko 
>> > > 
>> > >> So, maybe better we could omit \textcompwordmark in mono fonts.
>> > 
>> > > This patch works for me. It uses vphantom{}, but only between '<<' and 
>> > > '>>'.
>> > 
>> > See my other post for alternatives solving the "missing character" error
>> > with Unicode fonts for \textcompwordmark.

>> I have read it. I understand the usage and I don’t insist on removing
>> textcompwordmark any longer.

>> I don't insist. I would insist on removing textcompwordmark in mono
>> fonts, but did not see an easy way.

> It turned out, it is easy.

But it is still wrong: 

* It is LyX policy to keep LaTeX output stable (unless it turns out to be
  wrong).

* \textcompwordmark is the correct LaTeX internal character
  representation (LICR) for u200C (zero width non joiner, ZWNJ).

  If some fonts are missing this character this is a bug in the fonts or
  in the code calling this missing character (here tu1enc.def in latex/base/).
  
* The workaround should fix the command, not use a different
  one. Power users are then still able to override our workaround with
  their own re-definition of \textcompwordmark.


* Actually, in the case of ZWNJ, just dropping the missing character results
  in correct output. 
  --> We don't even need to add a workaround, if we remove
the "warning to error conversion for missing characters" for this case.



> Output for desired ligatures with the attached patch is:
>   "\\vphantom{}" if mono mono-fonts
>   "\\textcompwordmark " else.

This will only help for documents using DejaVu.  OTOH, it is not required
for Free* and no help for LatinModern.



...

> diff --git a/lib/doc/de/Additional.lyx b/lib/doc/de/Additional.lyx
> index 5ccd07b..539aa6d 100644
> --- a/lib/doc/de/Additional.lyx
> +++ b/lib/doc/de/Additional.lyx
> @@ -41,9 +41,9 @@ shapepar
>  \language_package default
>  \inputencoding auto
>  \fontencoding global
> -\font_roman "lmodern" "default"
> -\font_sans "lmss" "default"
> -\font_typewriter "lmtt" "default"
> +\font_roman "lmodern" "DejaVu Serif [bitstream]"
> +\font_sans "lmss" "DejaVu Sans [bitstream]"
> +\font_typewriter "lmtt" "DejaVu Sans Mono [bitstream]"
>  \font_math "auto" "auto"
>  \font_default_family default
>  \use_non_tex_fonts false

This fixes the test case but not the problem.

The correct fix is either an exception to the "error-on-missing-chars"
feature, or providing the workaround (re-defining to the original default):

  % ZWNJ missing in many Unicode fonts:
  \DeclareTextCommand{\textcompwordmark}{\UnicodeEncodingName}{%
 \leavevmode\kern\z@}

in LaTeXFeatures.cpp and "require" it in case \textcompwordmark is used in
documents with "non-TeX fonts" if configure detects TeXLive16 or later.

Günter

Re: Errors with vref on de/Additional.lyx with lualatex

[Guenter Milde]

On 2017-07-19, Kornel Benko wrote:



> I did as you proposed (Dejavu font), but maybe you are unaware that
> With TL15 everything compiles here

TL15 does not bind \textcompwordmark to the ZWNJ character but uses the
default definition also for Unicode fonts (EC1 and EC2).

> With TL16 I get missing glyphs if font is Dejavu, but not with Free*
>   Mark, that changing 'Dejavu Sans Mono' to e.g. 'Dejavu Sans' cures the 
> compilation though
> With TL17 I get missing glyphs for any font. I have to replace the mono font 
> to
> get it to compile.

In TL16, the font encoding used by "fontspec" (Xe/LuaTeX with "system
fonts") changed to TU: 

* In this encoding, \textcompwordmark is mapped to the ZWNJ character.

* Only some fonts actually contain this character.

* LyX turns the "missing character" WARNING into an ERROR
  This is usually a good thing (because printing characters that are missing
  represent data loss).
  
  For ZWNJ, it would be better if the warning was *not*
  turned into an error, because the ligature break works also if the
  character is missing -- no data loss, correct output!

> So, maybe better we could omit \textcompwordmark in mono fonts.

This would only cure the special case tested in the export tests. It will
not help in documents with the default LM or custom fonts where the serif
or non-serif fonts miss the ZWNJ. 
It would also not help in documents using the "ligature-break" special-char.


The better cure is one of

a) an exception list for the "turn missing character warning to error" code,

b) preamble code reverting the binding of \textcompwordmark to ZWNJ (at
   least for the next years until "system fonts" can be safely expected to
   ship with the ZWNJ character).
   
I prefer a), because the missing character still breaks the ligature (i.e.
the output looks as expected).

Günter

Re: export tests for beamer with TL17

[Guenter Milde]

On 2017-07-21, Kornel Benko wrote:

> OK, instead of \usepackage{fix-cm}
> the entry \usepackage{lmodern}
> works too. At least for pdflatex.

This also cures the use of dead ugly bitmapped EC fonts auto-substituted for
the default CM because LyX sets the font encoding to T1!

Please change the example(s) to use Latin Modern fonts.
Instead of inserting \usepackage{lmodern}, change the font settings
(in the GUI or in the lyx sources).

Any current LaTeX distribution supporting "beamer" should also ship
LModern fonts.


Günter

Re: Different LaTeX output when exporting than when previewing

[Guenter Milde]

On 2017-07-21, Scott Kostyshak wrote:
> On Tue, Jul 18, 2017 at 08:00:36AM +, Guenter Milde wrote:
>> 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).

> Good to know that this specific issue is not important, thanks Günter.
> Yes, I'm still worried about the underlying bug.

I am not sure this difference is a bug, it may just be some indeterminalism,
maybe caused by existence or non-existence of an auxiliary or chache file
(changing the order in which the secondary languages are "identified" by LyX).

Günter

Re: [LyX/master] We have new translation which slipped through the cracks.

[Jean-Pierre Chrétien]

Le 19/07/2017 à 13:51, Pavel Sanda a écrit :

Pavel Sanda wrote:

commit cd7b1dad6713e0dba2b90e7757fce5b0ca8e
Author: Pavel Sanda 
Date:   Wed Jul 19 13:36:06 2017 +0200

We have new translation which slipped through the cracks.


Scott, I am sorry I did not catch that before.

If/when you will be sending the announcement to translators for
RC, please add paragraph requesting ack for particular string
in layouttranslation table.

I guess we can get quick ack for de, de_alt, fr.


The current version of lib/layouttranslations is OK for French.

--
Jean-Pierre

Re: Any descriptions of the security aspects (related to needauth and shell-escape)?

[Scott Kostyshak]

On Thu, Jul 20, 2017 at 07:04:56PM +0200, Guillaume MM wrote:
> Le 19/07/2017 à 16:59, Richard Heck a écrit :
> > On 07/19/2017 02:22 AM, Christian Ridderström wrote:
> > > Hi,
> > > 
> > > When having tried to contribute to the discussion on needauth and
> > > shell-escape I've felt that it's quite difficult to get a good picture
> > > of things like:
> > > - Goals of design, what are we trying to achieve
> > > - Principle of design and system
> > > - Assumed threat models, and perhaps list threat scenarios we _don't_
> > > try to protect against
> > > 
> > > The e-mail threads are ... long, sometimes confusing and I suspect
> > > contains at least a few misunderstandings.  So I would like to ask
> > > (not being optimistic), if there's some design description anywhere?
> > 
> > No, as usual, there is not. The needauth mechanism was developed by
> > Tommaso in response
> > to security worries about certain sorts of converters, e.g., the ones
> > for R and related worries
> > about the use of gnuplot. (It may have been the latter that got him
> > interested.) Once that was on
> > board, Enrico decided to employ at least a somewhat similar mechanism to
> > support minted.sty,
> > and for whatever reason, that set off alarm bells which, in retrospect,
> > should have gone off
> > earlier. So we find ourselves in the middle of things.
> > 
> > Richard
> > 
> > 
> 
> Yes Richard, (smaller) alarm bells could have gone off a month earlier
> if I had paid attention to the gnuplot discussion. They went off when
> Scott explicitly asked about extending the use of needauth, and it did
> not seem to have changed the course of things.
> 
> For 2.3 Scott chose to ask "what can we do for LyX to be the safest?"
> rather than the obvious solution to get beta out. I find it reasonable
> and a worthwhile time investment.

I think the above summaries by Richard and Guillaume are accurate.

Scott


signature.asc
Description: PGP signature

Re: Any descriptions of the security aspects (related to needauth and shell-escape)?

[Scott Kostyshak]

On Wed, Jul 19, 2017 at 07:34:59PM +, Guenter Milde wrote:
> On 2017-07-19, Christian Ridderström wrote:
> 
> ...
> > ... I would like to ask (not being
> > optimistic), if there's some design description anywhere?
> 
> > I wonder because IMHO security requires a system wide approach and that
> > it's very easy to screw up if only looking at isolated pieces. Further, it
> > requires continuity so you know what you initially intended to achieve and
> > what you consider good enough. Otherwise you might later introduce a new
> > feature that inadvertently opens up a security whole. Without a system
> > design, it's also easy to get caught in discussions trying to bandaid a
> > small hole while missing entire walls missing.
> 
> > I think this kind of information would be good to gather and store in some
> > kind of design document, which could just be a text file in the repo.  Then
> > we could add knowledge to this document, and let if include the rationale
> > behind our choices, as well as letting developers review the system design.
> 
> I support the suggestion to create such a document and suppose to make it
> a section in "Development.lyx":
> 
> + bundled with other project policies and developer documentation
> + write access for all developers
> + we can use LyX's version control for to-be-reviewed parts and diverging
>   opinions/comments

+1

Development.lyx does not have a rigorous structure. If anyone is
interested in writing something more formal, when we can at reference
that file from within Development.lyx.


signature.asc
Description: PGP signature

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

[Scott Kostyshak]

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

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

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Overtake layout translations from fi.po, ja.po, zh_CN.po

[Jari-Matti Mäkelä]

Wed, 19 Jul 2017 13:41:17 +0200
Pavel Sanda  wrote:

> Pavel Sanda wrote:
> > Hi,
> > thanks, for the clarifications!
> > 
> > I see you removed the "luettelo" parts which is supposedly "List"
> > in your language. Are you sure about that change?

Yes, the common convention is not to write that in the PDF. I'll refer
to this as an official authority:

/usr/share/texmf-dist/tex/generic/babel-finnish/finnish.ldf

[code]
\addto\captionsfinnish{%
  \def\prefacename{Esipuhe}%
  \def\refname{Viitteet}%
  \def\abstractname{Tiivistelm\"a}
  \def\bibname{Kirjallisuutta}%
  \def\chaptername{Luku}%
  \def\appendixname{Liite}%
  \def\contentsname{Sis\"alt\"o}%   /* Could be "Sis\"allys" as well */
  \def\listfigurename{Kuvat}%
  \def\listtablename{Taulukot}%
  \def\indexname{Hakemisto}%
  \def\figurename{Kuva}%
  \def\tablename{Taulukko}%
  \def\partname{Osa}%
  \def\enclname{Liitteet}%
  \def\ccname{Jakelu}%
  \def\headtoname{Vastaanottaja}%
  \def\pagename{Sivu}%
  \def\seename{katso}%
  \def\alsoname{katso my\"os}%
  \def\proofname{Todistus}%
  \def\glossaryname{Sanasto}%
  }%
[/code]

We don't mention the word 'table' in the TOC either. The lists for
figures/tables aren't used that much in texts. There are some guides
for naming them in thesis / reports, but I couldn't find a single
authority that would be most correct and official one. I think this one
from babel-finnish would work the best. BTW wouldn't it be easier to
use that instead of hard coding the text in LyX?


> > If you have book with bunch of algorithm codes and you put
> > somewhere into appendix list of those, they will be introduced by
> > Algoritmit instead of Algoritmien luettelo. Was that intended?  
> 
> I just checked that all the "List" strings were recently checked by
> Martin Vermeer, so I think it was actually meant to be with
> "luettelo". (?)

I might have messed up some things when writing the
translations for the GUI. I feel the word 'luettelo/lista' might
clarify things in the GUI, but then again the printed version should
not show those. If both need to display the same, it might be
clearer to use the print version for both.

> > > > "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:  
> > > 
> > > I don't know either. Anyway, there has to be different
> > > translation, otherwise the two menu entries in outliner are not
> > > distinguishable.  

If they need different names, I'd use 'Kaavio / kaaviot' for
chart/charts and 'Graafi / graafit' or 'Diagrammi / diagrammit' for
some nonconventional graph/graphs. 'Kuvaaja' is just a synonym for
'kaavio'. I checked the translations and most presentations are called
chart <-> kaavio. That word covers most of the graphs/charts out there.

> > Graphs/Chart/Scheme are for papers written in layout for American
> > Chemical Society and apparently they don't even care to show Graph
> > example in their demo
> > ( http://mirrors.ctan.org/macros/latex/contrib/achemso/achemso-demo.pdf
> > ) so I think this particular tranaslation is not that important. 
> > > > 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.  
> > 
> > Most likely they are your 'structural formula'. 

The word for that would be 'Rakennekaava'. The word for 'chemical
equation' is 'Reaktiokaava'. I'd imagine the chemists want to enumerate
both, but don't know which one is more common if only one is supported.

> > > > 
> > > > "List of Listings"
> > > > "List of Program Listing"
> > > >   
> > > > -> Ohjelmalistaukset  
> > 
> > They are program code.

Right, so the 'ohjelmalistaukset' sounds more reasonable. I'm a
computer engineer myself and don't associate the word 'listaukset' with
program code. I can only guess the connection by knowing that the
package 'lstlisting' exists.

 - Jari-Matti

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

[Scott Kostyshak]

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

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

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

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

Scott


signature.asc
Description: PGP signature

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

[Scott Kostyshak]

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

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

True that's indeed an important difference.

Scott


signature.asc
Description: PGP signature

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

[Scott Kostyshak]

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

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

This is good. It shows the needauth implementation works.

> except if I disable needauth globally :(

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

Scott

Re: Different LaTeX output when exporting than when previewing

[Scott Kostyshak]

On Tue, Jul 18, 2017 at 08:00:36AM +, Guenter Milde wrote:
> 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
> 

Good to know that this specific issue is not important, thanks Günter.
Yes, I'm still worried about the underlying bug.

Scott

Re: [LyX/master] We have new translation which slipped through the cracks.

[Scott Kostyshak]

On Wed, Jul 19, 2017 at 01:51:55PM +0200, Pavel Sanda wrote:
> Pavel Sanda wrote:
> > commit cd7b1dad6713e0dba2b90e7757fce5b0ca8e
> > Author: Pavel Sanda 
> > Date:   Wed Jul 19 13:36:06 2017 +0200
> > 
> > We have new translation which slipped through the cracks.
> 
> Scott, I am sorry I did not catch that before.

I imagine this was my responsibility, actually. What command did you run
to make the above commit? Was it the following?

make layouttranslations1

> If/when you will be sending the announcement to translators for
> RC, please add paragraph requesting ack for particular string
> in layouttranslation table.

OK I added that to my checklist.

Thanks,

Scott

Re: export tests for beamer with TL17

[Kornel Benko]

Am Freitag, 21. Juli 2017 um 15:48:25, schrieb Kornel Benko 
> Am Freitag, 21. Juli 2017 um 15:37:05, schrieb Jürgen Spitzmüller 
> 
> > Am Freitag, den 21.07.2017, 13:58 +0200 schrieb Kornel Benko:
> > > The working cure for this lyx-file is to insert '\usepackage{fix-cm}' 
> > > into the preamble.
> > 
> > There are also other workarounds. See
> > http://texblog.net/latex-archive/latex-general/beamer-warnings/
> > 
> 
> Nice article, but does not help. (Probably I am too dumb)
> 

OK, instead of \usepackage{fix-cm}
the entry \usepackage{lmodern}
works too. At least for pdflatex.

Kornel

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

Re: export tests for beamer with TL17

[Kornel Benko]

Am Freitag, 21. Juli 2017 um 15:37:05, schrieb Jürgen Spitzmüller 

> Am Freitag, den 21.07.2017, 13:58 +0200 schrieb Kornel Benko:
> > The working cure for this lyx-file is to insert '\usepackage{fix-cm}' 
> > into the preamble.
> 
> There are also other workarounds. See
> http://texblog.net/latex-archive/latex-general/beamer-warnings/
> 

Nice article, but does not help. (Probably I am too dumb)

Kornel

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

Re: export tests for beamer with TL17

[Jürgen Spitzmüller]

Am Freitag, den 21.07.2017, 13:58 +0200 schrieb Kornel Benko:
> The working cure for this lyx-file is to insert '\usepackage{fix-cm}' 
> into the preamble.

There are also other workarounds. See
http://texblog.net/latex-archive/latex-general/beamer-warnings/

Jürgen

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

Re: export tests for beamer with TL17

[Kornel Benko]

Am Freitag, 21. Juli 2017 um 15:04:58, schrieb Kornel Benko 
> Am Freitag, 21. Juli 2017 um 13:58:49, schrieb Kornel Benko 
> > The working cure for this lyx-file is to insert '\usepackage{fix-cm}' into 
> > the preamble.
> 
> Hm, according to documentation of fix-cm, the tex source should start with
>   \RequirePackage{fix-cm}
> before \documentclass. How can that be achieved?
> We don't have any label in layouts like
>   AtStartOfPreamble
> 
> Interesting we already have the feature, so it is sufficient to add module 
> "fix-cm".
> 

Now tried with module fix-cm, but although the tex-part starts as expected, it 
does not
seem to use fix-cm.sty (according to latex log).
Moreover, it also prevents the use of \usepackage{fix-cm} later in the preamble.
So the only working case is my first try (adding to end of preamble).

Kornel

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

Re: export tests for beamer with TL17

[Jean-Marc Lasgouttes]

Le 21/07/2017 à 15:04, Kornel Benko a écrit :

Am Freitag, 21. Juli 2017 um 13:58:49, schrieb Kornel Benko 

The working cure for this lyx-file is to insert '\usepackage{fix-cm}' into the 
preamble.



Interesting we already have the feature, so it is sufficient to add module 
"fix-cm".


It would be even better to be able to use the feature automatically. Do 
you know why the error triggers in this case?


JMarc

Re: export tests for beamer with TL17

[Kornel Benko]

Am Freitag, 21. Juli 2017 um 13:58:49, schrieb Kornel Benko 
> The working cure for this lyx-file is to insert '\usepackage{fix-cm}' into 
> the preamble.

Hm, according to documentation of fix-cm, the tex source should start with
\RequirePackage{fix-cm}
before \documentclass. How can that be achieved?
We don't have any label in layouts like
AtStartOfPreamble

Interesting we already have the feature, so it is sufficient to add module 
"fix-cm".

Kornel

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

export tests for beamer with TL17

[Kornel Benko]

Hi,
these tests fail with TL17 (because of missing ecss0400.tfm)

3284:DEFAULTOUTPUT_export/examples/beamer_pdf2
3291:export/examples/beamerlyxexample1_dvi
3294:export/examples/beamerlyxexample1_pdf
3295:export/examples/beamerlyxexample1_pdf2
3296:export/examples/beamerlyxexample1_pdf3
3307:export/examples/beamerposter_dvi
3310:export/examples/beamerposter_pdf
3311:export/examples/beamerposter_pdf2
3312:export/examples/beamerposter_pdf3
4493:DEFAULTOUTPUT_export/examples/de/beamer_pdf2
4967:DEFAULTOUTPUT_export/examples/fr/beamer_pdf2
5320:DEFAULTOUTPUT_export/examples/ja/beamer_pdf
5321:export/examples/ja/beamer_pdf3
6028:export/templates/beamer-conference-ornate-20min_dvi
6031:export/templates/beamer-conference-ornate-20min_pdf
6032:export/templates/beamer-conference-ornate-20min_pdf2
6033:export/templates/beamer-conference-ornate-20min_pdf3
6052:export/templates/de_beamer-conference-ornate-20min_dvi
6055:export/templates/de_beamer-conference-ornate-20min_pdf
6056:export/templates/de_beamer-conference-ornate-20min_pdf2
6057:export/templates/de_beamer-conference-ornate-20min_pdf3
6116:export/templates/es_beamer-conference-ornate-20min_dvi
6119:export/templates/es_beamer-conference-ornate-20min_pdf
6120:export/templates/es_beamer-conference-ornate-20min_pdf2
6121:export/templates/es_beamer-conference-ornate-20min_pdf3
6132:export/templates/fr_beamer-conference-ornate-20min_dvi
6135:export/templates/fr_beamer-conference-ornate-20min_pdf
6136:export/templates/fr_beamer-conference-ornate-20min_pdf2
6137:export/templates/fr_beamer-conference-ornate-20min_pdf3
6196:DEFAULTOUTPUT_export/templates/ja_beamer-conference-ornate-20min_pdf
6198:export/templates/ja_beamer-conference-ornate-20min_pdf3

Looking for instance into latex log for beamer-conference-ornate-20min_pdf2, I 
see
! Font T1/cmss/m/n/4=ecss0400 at 4.0pt not loadable: Metric (TFM) file 
not found
The working cure for this lyx-file is to insert '\usepackage{fix-cm}' into the 
preamble.

In fact, it made all the mentioned tests pass.

Should we change the lyx-files?

Kornel

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