Re: [patch] update PDF viewers in configure.py

[Uwe Stöhr]

El 31.07.2017 a las 19:50, Christian Ridderström escribió:


The reason for my reluctance is probably:
- Any risk of licensing-related issues, i.e. is Master PDF honouring SW
licenses correctly.


Please. Since when are we there to judge other software? The user is 
free to decide what he likes. LyX should just offer to select and detect 
different PDF viewers.


Besides this, we already support Acrobat Reader: Closed source, 
non-free, special license, its usage is a potential security risk since 
it tries to put your documents to its cloud... But this is nothing we 
have to take care of. Users who don't want this, can use something else.


---

Meanwhile I contacted the Master PDF devs and indeed the responded 
quickly. I reported the problem that an executable name 
"masterpdfeditor4" is a problem for use and that we won't spend time to 
check the different version numbers. Moreover, on Windows the name of 
the executable is just "masterpdfeditor". The will discuss this.


So unless the name of the executable is not uniform on all OSes, I won't 
support it. Thus I retract my patch.


I still think however that we should remove KPDF and KGhostscript. 
However as we are in a feature freeze, I would postpone this to LyX 2.4.


regards Uwe

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

[Christian Ridderström]

On 1 August 2017 at 21:24, Richard Heck  wrote:

> On 08/01/2017 04:54 AM, Scott Kostyshak wrote:
> > On Tue, Aug 01, 2017 at 02:35:27AM +0200, Pavel Sanda wrote:
> >> Pavel Sanda wrote:
> >>> I did not hear your reaction to it either.
> >> I see you just did that, sorry... P
> > I believe that except for Enrico and I, everyone who participated in
> > this conversation has voted.


Hi Scott,

For the record, I'm not sure why I'm not included in people who particpated
but haven't voted.
Anyway, you're the release manager so your decisions goes.


> Uwe was interested in voting, but as the
> > vote stands currently, his vote would not change the outcome. I don't
> > have indication that any other LyX developer is interested in voting.
> >
> > The results are the following:
> >
> > 1: Guillaume (hesitantly [1]), .5 Pavel
> > 2: .5 Pavel
> > 3: Kornel, JMarc, Jürgen, Richard
> >
> > Option 3 wins the vote. My decision is to go forward with Enrico's
> > latest patch for beta1.
> >
> > Because the vote was not a blowout, and because I did not represent the
> > opinions of at least Guillaume and Pavel in the options, we will have
> > another vote two weeks after beta1 is released. Each developer may
> > propose one option that will be included in the vote.
>

As a side note, my opinion was likely also not represented, but I think you
have a feeling for my general thoughts.



> > So to be clear: although we are going to release beta1 with minted
> > support, depending on the post-beta1 vote, we may decide to remove it.
>
> It's obviously up to you, Scott, as release manager, but I agree with
> Enrico, to some extent, that this isn't the best policy.



> We have spent an enormous amount of time on this and finally have come to
> some kind of resolution. It really would be best to close that part of the
> debate and spend our time figuring out how to make the needauth
> and shell-escape stuff as secure as we can make it, given the present
> framework. Time spent re-litigating the questions about the framework is
> going to be wasted time.
>

Hi Richard,

It sounds like you complain about the time spent on discussing what I
assume is not just the minted patch but safety/security in general.
However, regarding spending to much time discussing safety, I can't help
but think about LyX 2.2 where something was obviously missing in terms of
safety.
That leads me to conclude that something was missing, or went awry, in the
development process of LyX 2.2. This, combined with you advocating

 "... spend our time figuring how to make the needauth and shell-escape
stuff as secure
  as we can make it, given the present framework"

makes me a little concerned.

It sounds like you argue for a release of 2.3 regardless of the absolute
achieved level of safety, because:
a) we've anyway done all that can be done using the needauth framework.
b) it's anyway better than LyX 2.2.

Would you mind clarifying your point of view?

Is it perhaps that in your mind the needauth solution is already good
enough, or that you're confident it can be made good enough?
If so, could you perhaps expand on why?

Or do you perhaps consider safety/security less important than other
aspects?
Perhaps compare to releasing before some date, or ensuring ease-of-use for
advanced users or perhaps something else?

Best regards,
/Christian

We can always decide to remove things, especially before a major release.
> If there are serious
> problems or concerns that arise during testing, then those can be
> raised at that point. Or if one
> or more of us who preferred the present course has doubts, we can
> raise those. But simply
> having another vote (a rare enough occurrence around here) just
> because people weren't
> entirely happy with how the options were presented doesn't strike me as a
> good idea. There
> is no indication I can see that the people who voted (3) might, let alone
> would, have voted
> differently had the other options been differently described. I think
> we all understood well
> enough what the broad issue was.
>

Discussing minted/safety/etc (Was: Options for resolving the minted + shell-escape issue)

[Christian Ridderström]

Richard wrote:

> We have spent an enormous amount of time on this ...
>

Hi,

Some thoughts regarding the discussion of safety and design of security
measures, i.e. a kind of "lessons learned" regarding the discussion aspects.

I think one thing that made things slower and more inefficient was a lack
of any self-contained description[*] of the overall design regarding safety
and security. Ideally I think the discussion would've benefited from having
one for:
- LyX version 2.2, i.e. the release with the big problems
- What was in master/HEAD, and at least was on its way to become LyX 2.3
- Intended eventual design, for LyX 2.3 or possibly a later release.

The long threads likely by now do contain a lot of separate pieces of
description, but it's unfortunately not so easy (at least for me) to find
this information among all the posts.
And sometimes I'd probably not understand to which "release" the
information pertains.

A partial "fix" might be to create a "best of"-list of posts with useful
descriptive information. Or perhaps to copy them to into one place, adding
minor markup as to what's still valid.
Or actually try to write down some design design description.

Question: Is there anyone who feels they know/understand the big picture
regarding safety/security?
Because I guess we in theory instead of writing things down could have a
designated "guru".

Actually, I'm a little worried that no one really has the big picture of
the intended design regarding safety and security.

Also, that different people have different ideas of where we are going and
what's considered needed, while we at the same time are not aware of these
differences.

For something (a "feature") much less complicated than safety/security, I
think it'd be fine for LyX if only a very small number of people know that
part, and to where they intend to go. And that everything else is in the
code. But for a complicated topic like safety, and when asking people to
vote, I think the lack of a description is a problem.

Hmm, and perhaps in case of votes, Scott should (be allowed to) weigh them
differently depending on the persons knowledge. E.g., since I don't
know/understand the (intended) safety design, why should my vote count as
much as a potential safety "guru".

On a more practical level:
Hindsight is 20-20, but regarding e.g. Enrico's patch, perhaps we should
have created a branch representing that alternative?   This would have
allowed that branch to always represent the latest improvement, thus
avoiding people testing out an older patch accidentally.
So we should keep the possibility of using branches in mind for future
discussions.

Perhaps there's other more practical things we could've done to make life
easier.

Best regards,
/Christian

[*] Regarding SW design descriptions and actually being able to understand
and review an intended design in advance, I'm probably a bit "damaged" from
when I worked with satellite software (AOCS), e.g. as SW verification and
validation manager.

In that field, lots of documentation was required which often was annoying,
but for complicated stuff like FDIR (making the SW/satellite be able to
cope with equipment failures), it really was essential to have the overall
picture. The reason being that a tiny change in one area of the system
could easily cause big problems in other areas, i.e. it's about unintended
consequences.

Here I see several similarities between FDIR and the safety/security for
LyX, e.g. that adding a neat feature like previews of Gnuplot figures
could've led to a big security hole.

Another similarity is that you can't do FDIR only at a low level, you need
a system perspective.
I think it's the same with safety/security for LyX: If we only consider
each feature separately, we're going to screw up. Two features in isolation
might be safe, but when available together it might "leak".

Another similarity is needing to define our objectives, and what we
consider "good enough" safety. If we don't understand what we're trying to
achieve, it's e.g. not possible to review a design to see if it achieves
the objectives.

Long threads? / list etiquette? (Was: Options for resolving the minted + shell-escape issue)

[Christian Ridderström]

Richard wrote:

> We have spent an enormous amount of time on this ...
>

HI,

Regarding the discussion of LyX's safety I'd like to make a few remarks
related to ... ?list etiquette? Not sure what the correct term should be,
but it ought to be clear below.

Really long threads:
Are we really ok with threads containing upwards a hundred posts?
Perhaps at some point it's necessary to simply start the thread over?

Thread splitting:
I've tried to break off topics into separate threads, but it _seems_ like
it's mainly me doing that.
Or maybe it's how the gmail interface presents the thread to me?

Is it something we're not doing anymore.
Should thread splitting be avoided, or should we try to do it more?


I'm using gmail's web interface these days. This might be why I'm finding
it difficult to efficiently follow threads that are so long.
- The gmail labs thing I used for replying to parts of an e-mail is no
longer working.
- Sometimes the replies don't go to the list. *sigh*
- I haven't figured out how to mark a single e-mail as unread,
  e.g. when I feel I need to reply to it later, and instead have to mark
the entire thread.
  This does _not_ work well for long threads.


Are there other things we could've done to do the discussion more
efficiently?

Using a wiki page for security topics didn't seem like it's (so far) helped
anything.
Would a LyX document in git have been better?
Or a plain text file?
/Christian

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

[Christian Ridderström]

On 1 August 2017 at 01:25, Pavel Sanda  wrote:

> Christian Ridderström wrote:
> > Please note that I'm _not_ wholly against something like needauth, I'm
> simply
> > not convinced it's good enough.  In fact, I'm still unclear on exactly
> how it
> > currently works, or perhaps rather, how it's intended to work in LyX 2.3.
>
> I already wrote you possible ways how we can cement the current situation
> more
> and IIRC you did not picked any.


Would you mind pointing me to that post?
I don't know if I simply missed it or was unable to read/consider/reply at
the time.

Meanwhile Tommaso committed patch which is
> slightly improving situation by "scary dialog". I did not hear your
> reaction to
> it either.
>

As you noticed in a later post, I did react to that.


> > > Even after all discussion I still see adding the whole needauth
> machinery
> > > as unnecessary complication of code and UI; possible future use of
> pygments
> > > still seems as made up argument for the sake of discussion rather than
> real
> > > user demand.
> >
> > Would you mind clarifying why needauth is an "unneccessary complication
> of
> > code and UI"?  (Apologies as I'm likely asking you to repeat what you've
> said
> > previously).
>
> I meant extending needauth mechanisms beyond current gnuplot/knitr usage
> for the sake of minted, because I believe minted maintainer will deliver
> us fix within couple months.
>

Ok, I understand what you mean.


> With such sight in view, I would be just fine to let minted support in
> current fashion, tell people clearly in manual that adding --shell-escape
> is dangerous, let Uwe scream at us little bit and then be done with it.
>

Ok.

Guess it comes down to the number of expected minted users. If not very
high, it's a good enough solution.
If there'd be lots of minted users, risk increase that they accidentally
leave --shell-escape in place.
/Christian

Re: Regarding safety/security, the DOCX and DOCM formats of MS Office

[Christian Ridderström]

On 1 August 2017 at 10:54, Scott Kostyshak  wrote:

> On Tue, Aug 01, 2017 at 02:26:52AM +0200, Christian Ridderström wrote:
>
> > Anyway, I'm not really advocating a new file extension like '.lyxm', but
> > simply trying to illustrate that MS Office tries hard to keep the
> defaults
> > safe, to the extent of not permitting macros at all.
>
> Interesting idea. I didn't know they did that.
>

FYI, I've added what I wrote to the wiki safety page, as a reference in the
future.

/C

Re: r41086 - www-user/trunk/farm/cookbook/LyX

[Christian Ridderström]

On 1 August 2017 at 10:54, Scott Kostyshak  wrote:

> On Mon, Jul 31, 2017 at 09:45:55PM +0200, sa...@lyx.org wrote:
> > Author: sanda
> > Date: Mon Jul 31 21:45:55 2017
> > New Revision: 41086
> > URL: http://www.lyx.org/trac/changeset/41086
> >
> > Log:
> > Update master translation status for web.
> >
> > 2Scott:
> > $ cd ~/lyx/master/po
> > $ make i18n.inc
> > $ mv i18n.inc ~/lyx/www/farm/cookbook/LyX/i18n_trunk.inc
> > $ cd ~/lyx/www
> > $ svn ci
>
> Thanks,
>

The above seems like it'd be useful to document somewhere.

But...

Pavel, did you run the commands on your local machine?

If so, we probably need to do something on the wiki/www server to do an
 'svn update' in some folder?

/Christian


>
> Scott
>

Re: lyx executable built with cmake will not run

[Christian Ridderström]

On 1 August 2017 at 14:47, Jean-Pierre Chrétien  wrote:

>
> It does not work, I can confirm.
>
> Here is what I ran:
>
> $ git clone g...@git.lyx.org:lyx newmaster
> $ cd newmaster
> $ automake
> $ cd ../cbuildnm
> $ cmake -DLYX_ENABLE_EXPORT_TESTS=ON -DLYX_RELEASE=ON
> -DLYX_PROGRAM_SUFFIX=ON -DLYX_ENABLE_CXX11=AUTO -DLYX_USE_QT=QT5
> -DLYX_LOCALVERSIONING=ON ../newmaster
> $ make
>

Why are you running 'automake' above, is that really needed when using
cmake?
I thought I didn't need it on my mac at least...
The commands also don't clean any contents in ../cbuildnm, should that
perhaps be done?

/Christian

What kinds of "code" can be embedded in a LyX document and "run" from LyX?

[Christian Ridderström]

Hi,

For the purpose of discussions on safety/security and
needauth/shell-escape, I would like to have, and document, a more complete
picture of the different kinds of use scenarios where LyX causes code to be
executed that was either embedded in a LyX document, or or in some external
file (script) that's referenced from a LyX document.

I've added the text below as a new section ("Execution of code form LyX")
to the wiki page on safety/security, but it contains some questions:
http://wiki.lyx.org/Devel/SafetyAndSecurity#toc4

I also wonder if it's complete, i.e. if there are additional ways in which
LyX might cause code to be executed.

---
!!! Execution of code from LyX

This section is intended to provide details of the different ways in which
LyX can cause (potentially dangerous) code to be executed.
The code in question could be stored directly in the LyX document, i.e. in
the .lyx-file, or stored in an external file, e.g. a script, that's
referenced by the LyX document.

TBC: The LyX program itself cannot directly execute any code, potentially
dangerous or otherwise. The reason is that he LyX program does not contain
any interpreter or compiler. Instad, LyX must always invoke (call) a tool
external to LyX in order for any code to actually be executed.

So In what ways can a LyX document contain code, or reference eg. an
external script, that LyX can cause to be executed?

Here's an initial attempt at listing the cases:

 Document preamble
The document preamble can contain arbitrary LaTeX code.
* Code is stored in the .lyx-file
* Execution occurs only when LyX exports the document as e.g. PDF
* LyX invokes e.g. pdflatex to execute the LaTeX code
* If option 'shell-escpae' is provided to e.g. pdflatex, execution of the
LaTeX code can be dangerous
* Q: Is it dangerous if and only if the option shell-escape is passed to
e.g. pdflatex?
* Q: Are there differences regarding safety/security for pdflatex vs luatex
vs ...?

 ERT
The document can contain ERTs which contain LaTeX code.
* Code is stored in the .lyx-file
* Execution occurs as for the preamble.
* Q: Can the LaTeX code in an ERT be arbitrary (from the point of view of
safety), assuming shell-escape is active?

 Chunk insets
The document can contain "chunk insets" that can contain code, e.g. R-code
* Code is stored in the .lyx-file
* Execution occurs only when LyX exports the document as e.g. PDF
* LyX invokes an external tool to execute the code.
* Converter settings define which tool LyX will use and with what arguments
the tool is called.
* Q: What other languages than R are relevant for "chunk insets"?

 Graphics insets

The document can contain graphics insets that reference a gnuplot script
* Code is stored in an external file (script)
* Execution occurs at preview or when  related to exporting a document.
* Converter settings define which external tool that'll be used to execute
the code ???

Besides gnuplot, what about e.g. 'Graphviz'?

 Anything else?

Q: Is there anything else that can contain code or reference code?

---

Some additional questions:

What about using the 'minted' package?   How does that fit in with the
above.
It's not code manually added by the user, but code generated from some LyX
inset.
Or is it that we're sending a code listing to minted that sends it to
pygmentize, which might "execute" the code listing?


Is pure literate programming covered by the above?

Best regards,
Christian

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

[Richard Heck]

On 08/01/2017 04:54 AM, Scott Kostyshak wrote:
> On Tue, Aug 01, 2017 at 02:35:27AM +0200, Pavel Sanda wrote:
>> Pavel Sanda wrote:
>>> I did not hear your reaction to it either.
>> I see you just did that, sorry... P
> I believe that except for Enrico and I, everyone who participated in
> this conversation has voted. Uwe was interested in voting, but as the
> vote stands currently, his vote would not change the outcome. I don't
> have indication that any other LyX developer is interested in voting.
>
> The results are the following:
>
> 1: Guillaume (hesitantly [1]), .5 Pavel
> 2: .5 Pavel
> 3: Kornel, JMarc, Jürgen, Richard
>
> Option 3 wins the vote. My decision is to go forward with Enrico's
> latest patch for beta1.
>
> Because the vote was not a blowout, and because I did not represent the
> opinions of at least Guillaume and Pavel in the options, we will have
> another vote two weeks after beta1 is released. Each developer may
> propose one option that will be included in the vote.
>
> So to be clear: although we are going to release beta1 with minted
> support, depending on the post-beta1 vote, we may decide to remove it.

It's obviously up to you, Scott, as release manager, but I agree with
Enrico, to some extent,
that this isn't the best policy. We have spent an enormous amount of
time on this and finally
have come to some kind of resolution. It really would be best to close
that part of the debate
and spend our time figuring out how to make the needauth and
shell-escape stuff as secure as
we can make it, given the present framework. Time spent re-litigating
the questions about the
framework is going to be wasted time.

We can always decide to remove things, especially before a major
release. If there are serious
problems or concerns that arise during testing, then those can be raised
at that point. Or if one
or more of us who preferred the present course has doubts, we can raise
those. But simply
having another vote (a rare enough occurrence around here) just because
people weren't
entirely happy with how the options were presented doesn't strike me as
a good idea. There
is no indication I can see that the people who voted (3) might, let
alone would, have voted
differently had the other options been differently described. I think we
all understood well
enough what the broad issue was.

Richard

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

[Enrico Forestieri]

On Tue, Aug 01, 2017 at 04:54:05AM -0400, Scott Kostyshak wrote:
> 
> So to be clear: although we are going to release beta1 with minted
> support, depending on the post-beta1 vote, we may decide to remove it.

Sorry, but this is not fair. The option to remove support has been
just voted and it didn't pass. This is astonishing. Really.

-- 
Enrico

Re: lyx executable built with cmake will not run

[Kornel Benko]

Am Dienstag, 1. August 2017 um 14:47:36, schrieb Jean-Pierre Chrétien 

> Le 01/08/2017 à 10:57, Scott Kostyshak a écrit :
> > On Mon, Jul 31, 2017 at 06:23:07PM +0200, Jean-Pierre Chrétien wrote:
> >> Le 31/07/2017 à 18:09, Kornel Benko a écrit :
> >>
>  I don't understand, I can load bin/lyx2.3 all right now.
> 
> >>>
> >>> So everything works again?
> >>
> >> Seems to work, I've recompiled cbuildnmfrom scratch after editing the 
> >> options,
> >> I'll keep you posted.
> >
> > So in the end what was the problem? Was it the "b" in the CMake options?
> > I ask because I'm having a similar issue [1].
> 
> It does not work, I can confirm.
> 
> Here is what I ran:
> 
> $ git clone g...@git.lyx.org:lyx newmaster
> $ cd newmaster
> $ automake
> $ cd ../cbuildnm
> $ cmake -DLYX_ENABLE_EXPORT_TESTS=ON -DLYX_RELEASE=ON -DLYX_PROGRAM_SUFFIX=ON 
> -DLYX_ENABLE_CXX11=AUTO -DLYX_USE_QT=QT5 -DLYX_LOCALVERSIONING=ON ../newmaster
> $ make
> 
> And then
> 
> $ bin/lyx2.3
> support/Messages.cpp (247): No language given, nothing to load.
> Error: No system directory

I did exactly as you did, but here it works.
Please send me the CMakeCache.txt (privately?)

> 
> Unable to determine the system directory having searched
>   /ext/lyx/cbuildnm/share/lyx2.3/

This looks more like the install directory would be the build tree.
(If so, then it is wrong)

> Use the '-sysdir' command line parameter or set the environment variable
> LYX_DIR_23x to the LyX system directory containing the file `chkconfig.ltx'.
> 
> Same error as before, I guess I did not call the right executable when it 
> seemed 
> to work.
> 
> Might be due to 2fe59adbc;

Kornel



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

Re: lyx executable built with cmake will not run

[Jean-Pierre Chrétien]

Le 01/08/2017 à 10:57, Scott Kostyshak a écrit :

On Mon, Jul 31, 2017 at 06:23:07PM +0200, Jean-Pierre Chrétien wrote:

Le 31/07/2017 à 18:09, Kornel Benko a écrit :


I don't understand, I can load bin/lyx2.3 all right now.



So everything works again?


Seems to work, I've recompiled cbuildnmfrom scratch after editing the options,
I'll keep you posted.


So in the end what was the problem? Was it the "b" in the CMake options?
I ask because I'm having a similar issue [1].


It does not work, I can confirm.

Here is what I ran:

$ git clone g...@git.lyx.org:lyx newmaster
$ cd newmaster
$ automake
$ cd ../cbuildnm
$ cmake -DLYX_ENABLE_EXPORT_TESTS=ON -DLYX_RELEASE=ON -DLYX_PROGRAM_SUFFIX=ON 
-DLYX_ENABLE_CXX11=AUTO -DLYX_USE_QT=QT5 -DLYX_LOCALVERSIONING=ON ../newmaster

$ make

And then

$ bin/lyx2.3
support/Messages.cpp (247): No language given, nothing to load.
Error: No system directory

Unable to determine the system directory having searched
/ext/lyx/cbuildnm/share/lyx2.3/
Use the '-sysdir' command line parameter or set the environment variable
LYX_DIR_23x to the LyX system directory containing the file `chkconfig.ltx'.

Same error as before, I guess I did not call the right executable when it seemed 
to work.


Might be due to 2fe59adbc;

--
Jean-Pierre

Re: [LyX/master] UserGuide.lyx: accept and distribute description of inverted branches

[Uwe Stöhr]

  Original Message  
From: Scott Kostyshak
Sent: Dienstag, 1. August 2017 10:57

>  So I guess that for Additional, I will create a
> Changelog-Additional-LyX_23x.txt retaining only what is to be done once I've
> done the copy to es|fr[ja.
> CC'ing Uwe since I think he does not follow all conversations on the‎ list.

Sorry, I forgot to announce what we agreed to: I will take care for the 
UserGuide and JP for Additional and Customization. Math and EmbeddedObjects 
should be ready for 2.3.
JP will decide what suits best fir the files he is working on.

Regards Uwe 

Scott

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

[Kornel Benko]

Am Dienstag, 1. August 2017 um 11:10:09, schrieb Stephan Witt 
> Am 01.08.2017 um 10:54 schrieb Scott Kostyshak :
> > 
> > On Tue, Aug 01, 2017 at 02:35:27AM +0200, Pavel Sanda wrote:
> >> Pavel Sanda wrote:
> >>> I did not hear your reaction to it either.
> >> 
> >> I see you just did that, sorry... P
> > 
> > I believe that except for Enrico and I, everyone who participated in
> > this conversation has voted. Uwe was interested in voting, but as the
> > vote stands currently, his vote would not change the outcome. I don't
> > have indication that any other LyX developer is interested in voting.
> 
> Sorry for being late in the game - I followed the discussion closely and
> tried to make my mind on this. I patched LyX, installed the Python module
> plus pygmentize executable and tried to typeset the minted-listings example.
> 
> I had difficulties to understand the different options. Why? It worked
> on my side only after manually adding -shell-escape to the pdflatex converter.
> This I didn’t expect after the discussion.
> 
> Did I miss anything? If yes, then it would be good for the next round of 
> voting
> to give more precise hints how to test the discussed feature.

I suppose you missed the patch "shell-escape-auth-5.diff" from Enrico.
See https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg201331.html

Kornel

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

Re: [LyX features/properpaint] Fix caret painting

[Jean-Marc Lasgouttes]

I am not working on it anymore unless I get bug reports. I will merge it in 
2.4.0 asap.

JMarc

Le 1 août 2017 01:35:49 GMT+02:00, Pavel Sanda  a écrit :
>What is your strategy with features/properpaint? To continue piling up
>new patches on top of if or leave it for testing?
>
>Pavel

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

[Scott Kostyshak]

On Tue, Aug 01, 2017 at 11:10:09AM +0200, Stephan Witt wrote:
> Am 01.08.2017 um 10:54 schrieb Scott Kostyshak :
> > 
> > On Tue, Aug 01, 2017 at 02:35:27AM +0200, Pavel Sanda wrote:
> >> Pavel Sanda wrote:
> >>> I did not hear your reaction to it either.
> >> 
> >> I see you just did that, sorry... P
> > 
> > I believe that except for Enrico and I, everyone who participated in
> > this conversation has voted. Uwe was interested in voting, but as the
> > vote stands currently, his vote would not change the outcome. I don't
> > have indication that any other LyX developer is interested in voting.
> 
> Sorry for being late in the game - I followed the discussion closely and
> tried to make my mind on this. I patched LyX, installed the Python module
> plus pygmentize executable and tried to typeset the minted-listings example.
> 
> I had difficulties to understand the different options. Why? It worked
> on my side only after manually adding -shell-escape to the pdflatex converter.
> This I didn’t expect after the discussion.
> 
> Did I miss anything? If yes, then it would be good for the next round of 
> voting
> to give more precise hints how to test the discussed feature.

Thanks for testing the patch and for asking the question. The idea of
the patch is: adding -shell-escape automatically with minted support
could be viewed as dangerous (does the user really know what they are
doing?). So the viewer must check the box in document settings that
allows running external programs for that document. The advantage of
this is that you do not have to add -shell-escape globally to the
converter (which you might forget to remove).

Scott


signature.asc
Description: PGP signature

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

[Stephan Witt]

Am 01.08.2017 um 10:54 schrieb Scott Kostyshak :
> 
> On Tue, Aug 01, 2017 at 02:35:27AM +0200, Pavel Sanda wrote:
>> Pavel Sanda wrote:
>>> I did not hear your reaction to it either.
>> 
>> I see you just did that, sorry... P
> 
> I believe that except for Enrico and I, everyone who participated in
> this conversation has voted. Uwe was interested in voting, but as the
> vote stands currently, his vote would not change the outcome. I don't
> have indication that any other LyX developer is interested in voting.

Sorry for being late in the game - I followed the discussion closely and
tried to make my mind on this. I patched LyX, installed the Python module
plus pygmentize executable and tried to typeset the minted-listings example.

I had difficulties to understand the different options. Why? It worked
on my side only after manually adding -shell-escape to the pdflatex converter.
This I didn’t expect after the discussion.

Did I miss anything? If yes, then it would be good for the next round of voting
to give more precise hints how to test the discussed feature.

Stephan

> 
> The results are the following:
> 
> 1: Guillaume (hesitantly [1]), .5 Pavel
> 2: .5 Pavel
> 3: Kornel, JMarc, Jürgen, Richard
> 
> Option 3 wins the vote. My decision is to go forward with Enrico's
> latest patch for beta1.
> 
> Because the vote was not a blowout, and because I did not represent the
> opinions of at least Guillaume and Pavel in the options, we will have
> another vote two weeks after beta1 is released. Each developer may
> propose one option that will be included in the vote.
> 
> So to be clear: although we are going to release beta1 with minted
> support, depending on the post-beta1 vote, we may decide to remove it.
> 
> Thank you to everyone for your time on this issue.
> 
> Scott
> 
> 
> [1] 
> https://www.mail-archive.com/search?l=mid=olnv4p%24jjn%241%40blaine.gmane.org

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

[Scott Kostyshak]

On Mon, Jul 31, 2017 at 11:43:04AM +0200, Enrico Forestieri wrote:

> Corrected at 44babaf6.

Thanks, that works well. The only other comment I have is to possibly
instruct the user to reconfigure after installing the module. If I
recall, that's what we say in similar contexts.

Scott


signature.asc
Description: PGP signature

Re: lyx executable built with cmake will not run

[Scott Kostyshak]

On Mon, Jul 31, 2017 at 06:23:07PM +0200, Jean-Pierre Chrétien wrote:
> Le 31/07/2017 à 18:09, Kornel Benko a écrit :
> 
> > > I don't understand, I can load bin/lyx2.3 all right now.
> > > 
> > 
> > So everything works again?
> 
> Seems to work, I've recompiled from scratch after editing the options,
> I'll keep you posted.

So in the end what was the problem? Was it the "b" in the CMake options?
I ask because I'm having a similar issue [1].

Scott


[1]
https://www.mail-archive.com/search?l=mid=20170729231401.tj5fp6f3ujwvxs3t%40vilnius


signature.asc
Description: PGP signature

Re: [LyX/master] UserGuide.lyx: accept and distribute description of inverted branches

[Scott Kostyshak]

On Sun, Jul 30, 2017 at 10:45:19PM +0200, Jean-Pierre Chrétien wrote:
> Le 30/07/2017 à 22:20, Uwe Stöhr a écrit :
> > commit 5513e465893ae255f75aaecc304133ba01a89e08
> > Author: Uwe Stöhr 
> > Date:   Sun Jul 30 22:20:03 2017 +0200
> > 
> > UserGuide.lyx: accept and distribute description of inverted branches
> > ---
> >  lib/doc/Changelog-UserGuide-LyX_23x.txt |1 +
> 
> I see that you collect changes in the Changelog files.
> I had created a docUpdatesFor23.txt file.
> The difference, if I understand correctly, is that the Changelog files
> record only the changes remaining after you have exported in the de|es|fr|ja
> files, while the docUpdatesFor23.txt file records what is new in the 2.3
> documentation.
> 
> On my side, I have added to docUpdatesFor23.txt the corrections made by
> jürgen while translation Additional.lyx in German. So German Additional.lyx
> is already up to date. I have just finished to copy the changes in
> Additional to the Spanish version, so french and Japanese remain to be
> copied.
> 
> The drawback (an maybe unneccesary task) in docUpdatesFor23.txt is that I
> recorded all changes, even font changes, quote editions or sentences or
> paragraphs suppression which do not appear anymore in the localized file
> once copied. So I guess that for Additional, I will create a
> Changelog-Additional-LyX_23x.txt retaining only what is to be done once I've
> done the copy to es|fr[ja.

CC'ing Uwe since I think he does not follow all conversations on the
list.

Scott


signature.asc
Description: PGP signature

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

[Scott Kostyshak]

On Mon, Jul 31, 2017 at 11:57:55PM +0200, Christian Ridderström wrote:

> Do we have an overview somewhere (with patch reference) for the
> alternatives proposed for beta1, which is then what's likely to end up in
> 2.3?
> Note: I did just look at the wiki page but didn't see it there clearly.

No we don't have anything on the wiki.

Scott


signature.asc
Description: PGP signature

Re: alpha beta lyx-formats and devel versions of the docs

[Scott Kostyshak]

On Sun, Jul 30, 2017 at 07:55:55PM +0200, Uwe Stöhr wrote:

> My personal policy is to stop working on the stable branch docs with the
> release of the first beta of a new version. This is just to save manpower.
> We have not released a beta yet, but I already started the doc updating for
> 2.3. So unless there is a compilation failure I would not backport info to
> the 2.2 branch anymore.

That makes sense to me. After beta, we hopefully won't have file format
changes so anyone who installs a beta or later can edit the newest
documentation. Even if we do have a file format change, we could
probably keep the documentation in beta format.

Scott


signature.asc
Description: PGP signature

Re: Regarding safety/security, the DOCX and DOCM formats of MS Office

[Scott Kostyshak]

On Tue, Aug 01, 2017 at 02:26:52AM +0200, Christian Ridderström wrote:

> Anyway, I'm not really advocating a new file extension like '.lyxm', but
> simply trying to illustrate that MS Office tries hard to keep the defaults
> safe, to the extent of not permitting macros at all.

Interesting idea. I didn't know they did that.

Scott


signature.asc
Description: PGP signature

Re: r41086 - www-user/trunk/farm/cookbook/LyX

[Scott Kostyshak]

On Mon, Jul 31, 2017 at 09:45:55PM +0200, sa...@lyx.org wrote:
> Author: sanda
> Date: Mon Jul 31 21:45:55 2017
> New Revision: 41086
> URL: http://www.lyx.org/trac/changeset/41086
> 
> Log:
> Update master translation status for web.
> 
> 2Scott: 
> $ cd ~/lyx/master/po
> $ make i18n.inc
> $ mv i18n.inc ~/lyx/www/farm/cookbook/LyX/i18n_trunk.inc
> $ cd ~/lyx/www
> $ svn ci

Thanks,

Scott


signature.asc
Description: PGP signature

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

[Scott Kostyshak]

On Tue, Aug 01, 2017 at 02:35:27AM +0200, Pavel Sanda wrote:
> Pavel Sanda wrote:
> > I did not hear your reaction to it either.
> 
> I see you just did that, sorry... P

I believe that except for Enrico and I, everyone who participated in
this conversation has voted. Uwe was interested in voting, but as the
vote stands currently, his vote would not change the outcome. I don't
have indication that any other LyX developer is interested in voting.

The results are the following:

1: Guillaume (hesitantly [1]), .5 Pavel
2: .5 Pavel
3: Kornel, JMarc, Jürgen, Richard

Option 3 wins the vote. My decision is to go forward with Enrico's
latest patch for beta1.

Because the vote was not a blowout, and because I did not represent the
opinions of at least Guillaume and Pavel in the options, we will have
another vote two weeks after beta1 is released. Each developer may
propose one option that will be included in the vote.

So to be clear: although we are going to release beta1 with minted
support, depending on the post-beta1 vote, we may decide to remove it.

Thank you to everyone for your time on this issue.

Scott


[1] 
https://www.mail-archive.com/search?l=mid=olnv4p%24jjn%241%40blaine.gmane.org


signature.asc
Description: PGP signature

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

[Scott Kostyshak]

On Tue, Aug 01, 2017 at 12:34:56AM +0200, Christian Ridderström wrote:

> So I think a very important question is if we think needauth is
> sufficiently good,
> or can be made sufficiently good before release.

My opinion is that yes.

> IMHO it's for LyX 2.3 not ok to do a release that's unsafe just because
> it's "less" unsafe
> than before, i.e. the release has to be sufficiently good, not just less
> bad than before.

The problem is that "sufficiently good" is an opinion. But yes, I agree
that "less unsafe" is not on its own good enough.

Scott


signature.asc
Description: PGP signature

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

[Scott Kostyshak]

On Mon, Jul 31, 2017 at 09:07:11PM +0200, Guillaume MM wrote:

> I am sure that Scott meant to include in some way the option that I have
> been advocating constantly from the beginning, which I understand is
> probably 1. (Otherwise, I do not see what the option 1. refers to nor
> who proposed it, and I would opt for not taking part in the vote.)

Yes my intention was to represent your opinion in a simplified way. I'm
sorry to have failed that. You will have an opportunity to write your
own option for the next vote (see separate email).

> So to
> be clear, my vote is 1., and the patch gives it substance as part of a
> larger proposition providing the most secure option for beta and for
> release so far (because after minted there remains to fix needauth). It
> just incidentally happens that it does not lock one into removing minted
> by providing a better basis for what people voting 3. are trying to
> achieve.


> (In particular Scott, even if the route of 3. is voted for
> beta, this patch minus disabling of minted remains an option for 2.3.)

Yes, I agree.

> As for your counting of votes, calling the end of the poll, and deciding
> what fits or does not fit proposed options,

I should have fixed an amount of days (or some other stopping criteria)
when I opened the poll. I am taking notes of things I have done poorly,
and will try to improve things in the future.

Scott


signature.asc
Description: PGP signature