Re: qt4/Makefile.am patch from #10711

[Jean-Marc Lasgouttes]

Le 26/06/2017 à 01:47, Scott Kostyshak a écrit :

Does anyone feel comfortable pushing the patch recently posted at the
following trac issue?

 https://www.lyx.org/trac/ticket/10711


I did that now. I think we can backport it too.

JMarc

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

[Guillaume MM]

Hi Scott,

Le 25/06/2017 à 22:41, Scott Kostyshak a écrit :


Judging by the comments of gpoore, we do not want to wait for this for
2.3.0. But this does affect the discussion of what to do for 2.3.0,
since we might not want to introduce a workflow in 2.3.0 that we will
change soon after.


I agree.



But regardless of what we decide to do about minted specifically, there
is still the open question of what to do with other .lyx files that
require -shell-escape. I don't think we ship any besides the newly added
minted ones, but it might be relevant to whether we make it easy to
temporarily add the -shell-escape or whether we want to make it hard (to
discourage it), with the consequence that the user might forget to
remove it. Once we answer this question in general, then we can decide
what to do with minted.


Looking at the problem from the -shell-escape perspective looks like a
false simplification of the problem to me and is likely to limit your
perspectives.

It is clear that any implementation of -shell-escape will require a
compromise between security and usability, but it is not clear to me
that the compromise should be the same independently of the feature
being implemented (I am abstract because it is not clear what else is
being discussed apart from minted.sty).

For instance, one could decide that there is no fundamental reason that
an implementation of Pygments in lyx should require -shell-escape. This
means requiring users to think about whether they want to enable
arbitrary code execution from a document for the sole purpose of having
latex instead of lyx call Pygments (which might be convenient to latex
users but pointless to lyx users). The user, given the opportunity to
think about it, will conclude that it is absurd to have to compromise
security (at least I do).




If the answer to the general question is "yes, let's make it easy so
that the user is not encouraged to permanently change a converter that
they might forget about", then from what I understand, Enrico has
proposed a patch that does that so it is straight-forward to move on: we
can use that approach for minted for 2.3.0, and when the github issues
is fixed, then we can transition to a safer approach (but I suppose it
will depend on what version of minted the user has?).
> If the answer to the general question is "no, let's make it hard so that
the user is discouarged from adding -shell-escape without thinking about
it", then from what I understand, we do not make any changes to the
current state of master (i.e. we do not apply the patch proposed by
Enrico), but we still ship minted support as it is currently
implemented.


I have not seen anyone suggesting to ship minted support as currently
implemented.



I'm sure I got something wrong in my attempt to summarize the situation
and figure out what we must decide on, so can someone correct me and add
more details? Please do so without adding your opinion on what we
*should* do. I just want to know the potential options out there.




A possible course of action. For 2.3:

* Revert the work on minted for now (without reintroducing the
external template). The work done so far is likely not lost and can be
reintroduced if minted is made into a 3-step process in the future.

* Without minted.sty support in lyx, there is no need to hurry for an
implementation of -shell-escape between feature freeze and beta release.

* Let third parties currently encouraging the manual addition of
-shell-escape do so using the needauth mechanism. This is already an
improvement.

* Optionally improve the current needauth mechanism with various ideas
that have been explored for -shell-escape.


In the future:

* Do not add new unsafe default converters in lyx until the needauth
mechanism satisfies standard guidelines referred to in the other message.

* Encourage safe alternatives instead whenever possible.


Does everyone agree that the general question (of "make it easy or hard
for user to add -shell-escape") is important and must be addressed
before 2.3.0beta1, or did I miss something?



I find that the enhancement request came in a bit late in the 2.3
release process for such a sensitive issue, and that 2.3 already
improves the situation with the needauth mechanism. So, if we conclude
that an implementation of Pygments should not have to request
-shell-escape, then I do not agree that this question is important and
must be addressed before 2.3.0beta1 (besides, for me it is not
well-framed either).

Good luck.

Guillaume

Re: Integrate Pdfium

[Jean-Marc Lasgouttes]

Le 27/06/2017 à 11:26, Tim Hutt a écrit :

After having Lyx on OSX fail to load PDF previews for the Nth time the
thought occurs that relying on third party command line tools like
ImageMagick and Ghostscript, or even sips (which I believe is the
'fix') is horribly fragile and there is a better way.

Why not integrate Pdfium into Lyx? It's open source with a
non-restrictive license. Battle tested. You're never going to have
issues with commands changing their name or not being in the PATH or
whatever.

Plus it opens up new opportunities, e.g. an integrated render preview,
faster native resolution graphics previews, etc.


LyX uses the unix philosophy: do what we know how to, let other programs 
do the rest. For graphics, it means that:

* whatever is handled natively by Qt (e.g. svg) can be used directly
* the rest is done via external programs, that can be chained through 
our formats/converter system


The good news is that Qt people have been working on a PDFium wrapper
http://blog.qt.io/blog/2017/01/30/new-qtpdf-qtlabs-module/
and that native PDF rendering will eventually happen.

Now, there are tons of other PDF libraries, and it is probably an error 
to believe that something is better than sliced bread because the magic 
"google" word is written on it :)


But basically, what we want is, given a PDF file, to convert it to png 
or whatever and load it. Since we are not interested in interaction with 
the PDF file, I doubt that a library will really help us.


Concerning the actual macOS problem: can you describe a bit more what 
happens? I have to admit that the preview mechanism is a bit of a 
mystery to me. I suspect in particular that it still relies on dvi output.

Re: trac login link does not use https by default

[Scott Kostyshak]

On Mon, Jun 26, 2017 at 10:32:29AM +0200, Jean-Marc Lasgouttes wrote:
> Le 25/06/2017 à 22:23, Scott Kostyshak a écrit :
> > To reproduce, go to:
> > 
> >  http://www.lyx.org/trac
> > 
> > Then click on "login". The connection for entering your login and
> > password is not secure.
> > 
> > Note that it is secure if in the link I give above, https is used. I
> > think that the login link should always be secure.
> > 
> > Is this an easy fix for anyone?
> 
> As we already discussed, I think that the whole site should redirect to the
> https: version.

That would be great. I was thinking worst case scenario we can just hard
code a https link for the log in but yes a general solution would be
preferred.

Scott

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

[Scott Kostyshak]

On Tue, Jun 27, 2017 at 03:33:12PM +0200, Guillaume MM wrote:
> Hi Scott,
> 
> Le 25/06/2017 à 22:41, Scott Kostyshak a écrit :
> > 
> > Judging by the comments of gpoore, we do not want to wait for this for
> > 2.3.0. But this does affect the discussion of what to do for 2.3.0,
> > since we might not want to introduce a workflow in 2.3.0 that we will
> > change soon after.
> 
> I agree.
> 
> > 
> > But regardless of what we decide to do about minted specifically, there
> > is still the open question of what to do with other .lyx files that
> > require -shell-escape. I don't think we ship any besides the newly added
> > minted ones, but it might be relevant to whether we make it easy to
> > temporarily add the -shell-escape or whether we want to make it hard (to
> > discourage it), with the consequence that the user might forget to
> > remove it. Once we answer this question in general, then we can decide
> > what to do with minted.
> 
> Looking at the problem from the -shell-escape perspective looks like a
> false simplification of the problem to me and is likely to limit your
> perspectives.
> 
> It is clear that any implementation of -shell-escape will require a
> compromise between security and usability, but it is not clear to me
> that the compromise should be the same independently of the feature
> being implemented

What I think we all agree on is that we would like to ideally allow the
user to control the tradeoff between security and usability. Where I
think there is disagreement is on whether we take a paternalistic
approach of "are you sure you know what you're doing? Think very hard
about this before you do it" or a lax approach of allowing users to
shoot themselves in the foot. Should we treat LyX users like teenagers
or adults? I really don't know the answer.

> (I am abstract because it is not clear what else is
> being discussed apart from minted.sty).

Good point, it is hard to argue abstractly. We should think about other
potential uses of -shell-escape from within LyX, discuss how we think
each should be handled, and then try to decide on what the correct
overall approach should be to handle them.

> For instance, one could decide that there is no fundamental reason that
> an implementation of Pygments in lyx should require -shell-escape. This
> means requiring users to think about whether they want to enable
> arbitrary code execution from a document for the sole purpose of having
> latex instead of lyx call Pygments (which might be convenient to latex
> users but pointless to lyx users). The user, given the opportunity to
> think about it, will conclude that it is absurd to have to compromise
> security (at least I do).
>
> > If the answer to the general question is "yes, let's make it easy so
> > that the user is not encouraged to permanently change a converter that
> > they might forget about", then from what I understand, Enrico has
> > proposed a patch that does that so it is straight-forward to move on: we
> > can use that approach for minted for 2.3.0, and when the github issues
> > is fixed, then we can transition to a safer approach (but I suppose it
> > will depend on what version of minted the user has?).
> > > If the answer to the general question is "no, let's make it hard so that
> > the user is discouarged from adding -shell-escape without thinking about
> > it", then from what I understand, we do not make any changes to the
> > current state of master (i.e. we do not apply the patch proposed by
> > Enrico), but we still ship minted support as it is currently
> > implemented.
> 
> I have not seen anyone suggesting to ship minted support as currently
> implemented.

As currently implemented in master, I agree. I was referring to applying
Enrico's patch(es), which I thought appeased Jürgen's initial concerns.

> > I'm sure I got something wrong in my attempt to summarize the situation
> > and figure out what we must decide on, so can someone correct me and add
> > more details? Please do so without adding your opinion on what we
> > *should* do. I just want to know the potential options out there.
> > 
> 
> 
> A possible course of action. For 2.3:

Thank you for proposing a course of action. In order to move forward, we
need to get all proposals written down so that we can all participate in
making a decision.

> * Revert the work on minted for now (without reintroducing the
> external template). The work done so far is likely not lost and can be
> reintroduced if minted is made into a 3-step process in the future.
> 
> * Without minted.sty support in lyx, there is no need to hurry for an
> implementation of -shell-escape between feature freeze and beta release.
> 
> * Let third parties currently encouraging the manual addition of
> -shell-escape do so using the needauth mechanism. This is already an
> improvement.
> 
> * Optionally improve the current needauth mechanism with various ideas
> that have been explored for -shell-escape.
> 
> 
> In the future:
> 
> * Do not 

Re: allowing anonymous contributions to LyX's source code?

[Scott Kostyshak]

On Mon, Jun 26, 2017 at 02:16:26PM -0400, Richard Heck wrote:
> On 06/26/2017 11:40 AM, Christian Ridderström wrote:
> >
> > On 26 June 2017 at 10:31, Jean-Marc Lasgouttes  > > wrote:
> >
> >  From time to time, we receive patches from people who prefer
> > to remain
> > anonymous (e.g. use a nickname and not their real name). It
> > would be
> > nice if we had a clear policy on whether we are OK with this.
> >
> >
> > We cannot be sure that we know who is author of a patch. But we
> > can have a " best effort" policy. We already have in the repo a
> > contributor (venom00) who disclosed his real identity only
> > privately. I think this is a good trade-off.
> >
> >
> > +1
> 
> Agreed.

I'm fine with that.

I would like to clarify this in the Development.lyx manual. Does anyone
disagree with the following policy?

If a contributor of a patch would like to remain anonymous, our
policy is that they can reveal their identity privately to a LyX
developer. The LyX developers will make their best effort to never
use the real name of the contributor in public correspondence.

Does anyone disagree with this policy? Should they send their email to
one/two LyX developers or to develop...@lyx.org?

Scott

Re: Minted example not displaying in pdf anymore

[Scott Kostyshak]

On Tue, Jun 27, 2017 at 01:35:19AM +0200, Kornel Benko wrote:
> Am Montag, 26. Juni 2017 um 23:46:32, schrieb Enrico Forestieri 
> 
> > On Mon, Jun 26, 2017 at 01:51:08AM +0200, Enrico Forestieri wrote:
> > > On Sun, Jun 25, 2017 at 04:24:18PM -0400, Scott Kostyshak wrote:
> > > > 
> > > > True, but I think that is partly because we used to support GCC 4.6 and
> > > > Qt 4.8. We have never supported minted, so that is why I think it is
> > > > "more OK" if we do not support older versions. In the end, I suppose it
> > > > depends on how long it would take us to add support for older versions,
> > > > and on if that support would be hackish or would be a good
> > > > implementation.
> > > > 
> > > > Enrico, any thoughts on the above?
> > > 
> > > Taking into account older versions of Pygments that are case
> > > sensitive would be straightforward. It would suffice to lower
> > > case the language only when it is going to be written in the
> > > LaTeX file. Indeed, our GUI is case sensitive and the language
> > > combo gets disabled if the case does not match (meaning that the
> > > language can only be changed through the advanced tab).
> > 
> > I did this at 28be7d55.
> 
> Nice.

+1 thanks, Enrico.

Scott

Re: allowing anonymous contributions to LyX's source code?

[Joel Kulesza]

On Tue, Jun 27, 2017 at 1:00 PM, Scott Kostyshak  wrote:

>
> Does anyone disagree with this policy? Should they send their email to
> one/two LyX developers or to develop...@lyx.org?


I would recommend develop...@lyx.org to avoid pie truck incidents or
developer internal miscommunication; however, can "the general public" now
email to it?

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

[Enrico Forestieri]

On Tue, Jun 27, 2017 at 03:00:37PM -0400, Scott Kostyshak wrote:
> On Tue, Jun 27, 2017 at 03:33:12PM +0200, Guillaume MM wrote:
> > 
> > I find that the enhancement request came in a bit late in the 2.3
> > release process for such a sensitive issue, and that 2.3 already
> > improves the situation with the needauth mechanism. So, if we conclude
> > that an implementation of Pygments should not have to request
> > -shell-escape, then I do not agree that this question is important and
> > must be addressed before 2.3.0beta1 (besides, for me it is not
> > well-framed either).
> 
> I agree that it is late in the process, and indeed that does make
> stronger the proposal of "let's just revert". But this issue is not the
> only one holding up beta1. When we make progress on the other issues, if
> this one is still hanging in the air and we cannot agree on what to do,
> then we might need to move on and revert. My opinion is that we're not
> there yet.

I don't think that reverting is in discussion here, apart from the
(apparently, IMO) biased opinion of Guillame. The support for minted
is not risky in itself, otherwise any usage of generic latex packages
would be.

> Thanks for your logical arguments and your proposal.

Fuzzy logic, maybe. At the moment it is more risky the needauth option
than the minted support. But maybe I am forgetting that that was an
improvement. Ipse dixit .

-- 
Enrico

Re: allowing anonymous contributions to LyX's source code?

[Jean-Marc Lasgouttes]

The list is closed to outsiders indeed. We could open it, but we do not want it 
to be used as another lyx-devel. I think that the developer that received the 
information can forward the information to develop...@lyx.org if needed.

I am not convinced though that there is a pressing need to carve these things 
in stone.

JMarc

Le 27 juin 2017 21:10:54 GMT+02:00, Joel Kulesza  a écrit :
>On Tue, Jun 27, 2017 at 1:00 PM, Scott Kostyshak 
>wrote:
>
>>
>> Does anyone disagree with this policy? Should they send their email
>to
>> one/two LyX developers or to develop...@lyx.org?
>
>
>I would recommend develop...@lyx.org to avoid pie truck incidents or
>developer internal miscommunication; however, can "the general public"
>now
>email to it?

Re: allowing anonymous contributions to LyX's source code?

[Pavel Sanda]

Scott Kostyshak wrote:
> I would like to clarify this in the Development.lyx manual. Does anyone
> disagree with the following policy?
> 
> If a contributor of a patch would like to remain anonymous, our
> policy is that they can reveal their identity privately to a LyX
> developer. The LyX developers will make their best effort to never
> use the real name of the contributor in public correspondence.

By the the "best effort" policy we mean best effort on our part to know real
identity of the contributor, not how we treat his name, cf
https://en.wikipedia.org/wiki/Due_diligence
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg195648.html

That's the legal part. Last time when we talked about this, the major
issue was rather social aspect -- that we want to know who we are
collaborating with.

> Does anyone disagree with this policy? Should they send their email to
> one/two LyX developers or to develop...@lyx.org?

I think you are too bureaucratic by trying to declare all this stuff, anyway
couple of long-term core devs are enough :)

Pavel

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

[Tommaso Cucinotta]

On 20/06/2017 02:43, Guillaume MM wrote:

One must look at the
big picture and see that adding an authorization mechanism for arbitrary
execution of commands is absurd when its sole purpose is to call an
external tool from within LaTeX.


needauth was a urgently needed mitigation of the security issues behind running
arbitrary external tools when compiling LyX documents; a more engineered remedy
AFAICR was actually the use of sandboxing machineries, which was prototyped on
Ubuntu/Linux using AppArmor.


Lastly, I find interesting the idea of a "secure" icon providing visual
feedback and the ability to revoke the permissions, and I believe that
it could be used to improve the current needauth mechanism.


+1 for completing the current needauth with a revocation means; this can include
also a security settings pane where we list the pathnames of all documents in
the user's approved permission list, where one can revoke the permission 
selectively,
or even perhaps edit the list and use wildcards (e.g., always grant when I work
in /home/tommaso/work/trusted/*)... ok, I went too far :-)

My2c,

T.

searching lyx stuff on Google

[Tommaso Cucinotta]

Hi,

I was sure we had a wiki page on lyx.org about security issues and the need for 
hardening LyX against potential misuse, due to the risks in running external 
tools, write18{}, shell-escape, gnuplot / R / knitr et al., but perhaps I can't 
really remember.

However, I struggled in finding back

  http://www.lyx.org/trac/ticket/10481

even searching explicitly for "  Hardening LyX against potential misuse" on 
Google, I can only find mail-archive.com e-mail threads, restricting with site:lyx.org 
leads to no results in the search.

1) did we change anything in the website, so that LyX wiki pages are not 
indexed anymore by G. ?
2) did we actually have that wiki page on hardening LyX, or just the trac 
#10481 ?

Thanks,

T.

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

[Enrico Forestieri]

On Tue, Jun 27, 2017 at 11:45:56PM +0200, Tommaso Cucinotta wrote:
> On 20/06/2017 02:43, Guillaume MM wrote:
> > One must look at the
> > big picture and see that adding an authorization mechanism for arbitrary
> > execution of commands is absurd when its sole purpose is to call an
> > external tool from within LaTeX.
> 
> needauth was a urgently needed mitigation of the security issues behind 
> running
> arbitrary external tools when compiling LyX documents; a more engineered 
> remedy
> AFAICR was actually the use of sandboxing machineries, which was prototyped on
> Ubuntu/Linux using AppArmor.

I actually don't see where the urgency was. We were not distributing
dangerous converters. Instead, now we do and those converters can execute
arbitrary commands, so needauth is in the same board as shell escape and
trying to separate the two issues is only instrumental.

My 3c

-- 
Enrico

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

[Enrico Forestieri]

On Tue, Jun 27, 2017 at 03:00:37PM -0400, Scott Kostyshak wrote:
> On Tue, Jun 27, 2017 at 03:33:12PM +0200, Guillaume MM wrote:
> >
> > I find that the enhancement request came in a bit late in the 2.3
> > release process for such a sensitive issue, and that 2.3 already
> > improves the situation with the needauth mechanism. So, if we conclude
> > that an implementation of Pygments should not have to request
> > -shell-escape, then I do not agree that this question is important and
> > must be addressed before 2.3.0beta1 (besides, for me it is not
> > well-framed either).
>
> I agree that it is late in the process, and indeed that does make
> stronger the proposal of "let's just revert". But this issue is not the
> only one holding up beta1. When we make progress on the other issues, if
> this one is still hanging in the air and we cannot agree on what to do,
> then we might need to move on and revert. My opinion is that we're not
> there yet.

I don't think that reverting is in discussion here, apart from the
(apparently, IMO) biased opinion of Guillame. The support for minted
is not risky in itself, otherwise any usage of generic latex packages
would be.

> Thanks for your logical arguments and your proposal.

Fuzzy logic, maybe. At the moment it is more risky the needauth option
than the minted support. But maybe I am forgetting that that was an
improvement. Ipse dixit .

--
Enrico

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

[Tommaso Cucinotta]

On 28/06/2017 00:02, Enrico Forestieri wrote:

...and those converters can execute
arbitrary commands,


just to be sure, I just double-checked that on current trunk, without any settings in 
one's ~/.lyx/, the default behavior will be "Forbid use of needauth 
converters", so any of those dangerous ones would be disabled by default.

As for shell-escape, I couldn't go through the whole thread yet, but it seems 
very related, so it makes sense to be added as well. Whether in this release or 
next one, it's all up to the release master, though!

AFAICS, a reasonable (needauth-alike) behavior seems:
- a document-specific setting tagging the document as one needing to run latex 
with -shell-escape
- only when trying to run latex (or pdflatex, if it supports -shell-escape, or 
others), at the first attempt, trigger similar security questions as for 
needauth:
  a) the document needs to be compiled with this potentially harmful option, 
are you sure you want to do that ? (y)es, (a)lways for this doc, (n)o [(r)un 
without shell-escape ?]
  b) have another set of settings similar to needauth ones (or re-use them ?) 
that disable the question by default, so the user cannot choose (y)es unless 
changes explicitly the settings
- if one just opens the .lyx, makes edits, but never previews, nor needs to run 
latex, then no question pops up.

Just quick thoughts, though.

Good night.

T.

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

[Enrico Forestieri]

On Wed, Jun 28, 2017 at 12:25:58AM +0200, Tommaso Cucinotta wrote:
> On 28/06/2017 00:02, Enrico Forestieri wrote:
> > ...and those converters can execute
> > arbitrary commands,
> 
> just to be sure, I just double-checked that on current trunk, without any
> settings in one's ~/.lyx/, the default behavior will be "Forbid use of
> needauth converters", so any of those dangerous ones would be disabled by
> default.

At the moment there is no shell escape added when using minted, so it is
even more secure.

> As for shell-escape, I couldn't go through the whole thread yet, but it seems
> very related, so it makes sense to be added as well. Whether in this release
> or next one, it's all up to the release master, though!

I am not interested in this support. Don't need it, simply. I was taken
perforce in this debate. I tried to do my best to address the concerns
of various people. When Jürgen raised this question, I told him that this
would have been the same as opening a pandora's box.

What I can't stand is that someone is asking for reverting support for
a feature which in itself is less dangerous than needauth. It is this
kind of hypocrisy which is unbearable.

> AFAICS, a reasonable (needauth-alike) behavior seems:
> - a document-specific setting tagging the document as one needing to run 
> latex with -shell-escape
> - only when trying to run latex (or pdflatex, if it supports -shell-escape, 
> or others), at the first attempt, trigger similar security questions as for 
> needauth:
>   a) the document needs to be compiled with this potentially harmful option, 
> are you sure you want to do that ? (y)es, (a)lways for this doc, (n)o [(r)un 
> without shell-escape ?]
>   b) have another set of settings similar to needauth ones (or re-use them ?) 
> that disable the question by default, so the user cannot choose (y)es unless 
> changes explicitly the settings
> - if one just opens the .lyx, makes edits, but never previews, nor needs to 
> run latex, then no question pops up.
> 
> Just quick thoughts, though.

I proposed about 5 different patches all taking more or less into account
all of what you are saying. Again, for taking into account various concerns,
not because I wanted to have support for shell escape. Now I stop it here.
If someone wants to add support for shell escape, he can freely reuse the
patches I posted. I am out now.

Thank you for your balanced suggestions.

-- 
Enrico

Trac login design is broken.

[Tim Hutt]

1. Try to login with my usual username & password system.
2. Fails
3. Hmm I guess I forgot my password.
4. Enter username and email into the "Forgot my password" page.

"The email and username do not match a known account."

Ok what. That's stupid. You should only need the email address to
reset the password. Usernames are not passwords!

Anyway, maybe I didn't register.

5. Tries to register.

"The email address specified is already in use. Please specify a different one."

!!!

You guys should move to Github or Gitlab.

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

[Enrico Forestieri]

On Tue, Jun 27, 2017 at 03:33:12PM +0200, Guillaume MM wrote:
> 
> I find that the enhancement request came in a bit late in the 2.3
> release process for such a sensitive issue, and that 2.3 already
> improves the situation with the needauth mechanism. So, if we conclude
> that an implementation of Pygments should not have to request
> -shell-escape, then I do not agree that this question is important and
> must be addressed before 2.3.0beta1 (besides, for me it is not
> well-framed either).

I don't think that your opinion is sincere. I think that instead it
is again hypocritical. It was amusing reading that "I do not oppose
to needauth because it was an improvement, while shell escape is
a security hazard". They entail the same security risk, so either
you are really concerned about security or you are simply using
specious arguments. And i think that this last one is the case.
I was not specifically interested in minted support and was
actually encouraged in adding it. It seems that removing this
support is becoming the reason of your life for the simple pleasure
of hurting. I did not expect anything better from you, frankly.

-- 
Enrico

Re: Trac login design is broken.

[Kornel Benko]

Am Dienstag, 27. Juni 2017 um 10:19:45, schrieb Tim Hutt 
> 1. Try to login with my usual username & password system.
> 2. Fails
> 3. Hmm I guess I forgot my password.
> 4. Enter username and email into the "Forgot my password" page.
> 
> "The email and username do not match a known account."
> 
> Ok what. That's stupid. You should only need the email address to
> reset the password. Usernames are not passwords!
> 
> Anyway, maybe I didn't register.
> 
> 5. Tries to register.
> 
> "The email address specified is already in use. Please specify a different 
> one."
> 
> !!!
> 
> You guys should move to Github or Gitlab.

I had the same. The protocol changed from http to https. If you are not using
cookies for this 'new' page, then you cannot login.

Kornel


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

Integrate Pdfium

[Tim Hutt]

After having Lyx on OSX fail to load PDF previews for the Nth time the
thought occurs that relying on third party command line tools like
ImageMagick and Ghostscript, or even sips (which I believe is the
'fix') is horribly fragile and there is a better way.

Why not integrate Pdfium into Lyx? It's open source with a
non-restrictive license. Battle tested. You're never going to have
issues with commands changing their name or not being in the PATH or
whatever.

Plus it opens up new opportunities, e.g. an integrated render preview,
faster native resolution graphics previews, etc.

Re: allowing anonymous contributions to LyX's source code?

[Richard Heck]

On 06/27/2017 08:36 PM, Scott Kostyshak wrote:
> On Tue, Jun 27, 2017 at 11:41:55PM +0200, Pavel Sanda wrote:
>> Scott Kostyshak wrote:
>>> I would like to clarify this in the Development.lyx manual. Does anyone
>>> disagree with the following policy?
>>>
>>> If a contributor of a patch would like to remain anonymous, our
>>> policy is that they can reveal their identity privately to a LyX
>>> developer. The LyX developers will make their best effort to never
>>> use the real name of the contributor in public correspondence.
>> By the the "best effort" policy we mean best effort on our part to know real
>> identity of the contributor, not how we treat his name, cf
>> https://en.wikipedia.org/wiki/Due_diligence
>> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg195648.html
>>
>> That's the legal part. Last time when we talked about this, the major
>> issue was rather social aspect -- that we want to know who we are
>> collaborating with.
> OK I guess I should avoid the phrase "best effort" then. I just wanted
> to signal that although we would do our best to not use their real name,
> it is understandable if sometime a mistake was made.
>
>>> Does anyone disagree with this policy? Should they send their email to
>>> one/two LyX developers or to develop...@lyx.org?
>> I think you are too bureaucratic by trying to declare all this stuff, anyway
>> couple of long-term core devs are enough :)
> I've seen situations where we say different things on the same topic.
> That is why I think it is nice to have a proper discussion, get our
> opinions out in the open, and figure out our position so we don't have
> to keep coming back to it. Putting it in the Development.lyx doesn't
> mean we won't change it. But it gives us a starting point that we can
> tweak if needed.

It's come up more than once, so I think it's worth writing down what
we've decided. Obviously, we can revisit the issue any time we like. But
we won't have to re-discuss it every time.

Richard

Re: allowing anonymous contributions to LyX's source code?

[Joel Kulesza]

On Tue, Jun 27, 2017 at 7:24 PM, Richard Heck  wrote:

>
> It's come up more than once, so I think it's worth writing down what
> we've decided. Obviously, we can revisit the issue any time we like. But
> we won't have to re-discuss it every time.


This is why I'd like to see the approach written down as well.

Re: allowing anonymous contributions to LyX's source code?

[Scott Kostyshak]

On Tue, Jun 27, 2017 at 11:36:27PM +0200, Jean-Marc Lasgouttes wrote:

> I think that the developer that received the information can forward the 
> information to develop...@lyx.org if needed.

This makes sense.

> I am not convinced though that there is a pressing need to carve these things 
> in stone.

I agree it's not pressing, and I guess we have enough other debates
going on, but on the other hand it is nice to figure out what our policy
is on recurring topics.

Scott


signature.asc
Description: PGP signature

Re: allowing anonymous contributions to LyX's source code?

[Scott Kostyshak]

On Tue, Jun 27, 2017 at 11:41:55PM +0200, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > I would like to clarify this in the Development.lyx manual. Does anyone
> > disagree with the following policy?
> > 
> > If a contributor of a patch would like to remain anonymous, our
> > policy is that they can reveal their identity privately to a LyX
> > developer. The LyX developers will make their best effort to never
> > use the real name of the contributor in public correspondence.
> 
> By the the "best effort" policy we mean best effort on our part to know real
> identity of the contributor, not how we treat his name, cf
> https://en.wikipedia.org/wiki/Due_diligence
> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg195648.html
> 
> That's the legal part. Last time when we talked about this, the major
> issue was rather social aspect -- that we want to know who we are
> collaborating with.

OK I guess I should avoid the phrase "best effort" then. I just wanted
to signal that although we would do our best to not use their real name,
it is understandable if sometime a mistake was made.

> > Does anyone disagree with this policy? Should they send their email to
> > one/two LyX developers or to develop...@lyx.org?
> 
> I think you are too bureaucratic by trying to declare all this stuff, anyway
> couple of long-term core devs are enough :)

I've seen situations where we say different things on the same topic.
That is why I think it is nice to have a proper discussion, get our
opinions out in the open, and figure out our position so we don't have
to keep coming back to it. Putting it in the Development.lyx doesn't
mean we won't change it. But it gives us a starting point that we can
tweak if needed.

But I'm not sensing there is much support for having a rule on this, so
I'm going to hold off.

Thanks to all for the discussion,

Scott


signature.asc
Description: PGP signature