New Win installer for LyX 2.2.2 available

[Uwe Stöhr]

Hello Richard,

could you please put this new installer version 3 to ftp.lyx.org?:
http://ftp.lyx.de/LyX%202.2.2/

The background is that MiKTeX refactored its whole package handling 
system. Therefore users who updated their LaTeX packages during the last 
3 weeks got a lot of troubles. At least I had many and I also got mails 
from users. With the new installer people having problems could 
reinstall LyX _and_ MiKTeX to get again a running system.


When it is at ftp.lyx.org I would announce it on lyx-users with an 
explanation what to do if users have already problems with LaTeX.


many thanks and regards
Uwe

Re: #10481: Hardening LyX against potential misuse

[Tommaso Cucinotta]

On 27/11/2016 13:52, Guillaume Munch wrote:

Hi Tommaso,


Hi,


[...] Making AppArmor work would be
great too, but I suspect that it is going to be hard to have a
configuration which is both secure and without hassle to the user,


right, security comes often at a usability cost, hopefully we can
keep hassle at the very bare minimum, and showing up only for
advanced/particular usage scenarios.


Le 23/11/2016 à 22:27, Tommaso Cucinotta a écrit :

One note: one way to avoid the [auth session] section growing unbounded,
might be to have an expiry timestamp, so that e.g., authorizations would
expire in ~1y or so. This might be done with a section syntax like:

   

instead of the simple  we have now.


Could that be used to fix #10310 as well?
See https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg195888.html


eh eh, what about remembering 'needauth' (as well as cursor pos) only for
those files in the recent files list :-), and collapse the 3 lists into
a single one, and a single session section ?


* Please see the attached patch for a few suggestions


looks great, HTML provides a much better graphics :-), feel free to push !

As for the type of possible damages, it's likely beef for the User Manual,
and probably we need to redirect the user there, to know more if needed.


few corrections, html formatting, no checkbox). (Using html much
improves readability, but then the html appears in the console output. I
have a solution for this if you choose this route.)


and feel free to apply the corresponding workaround...


* Converters>Security is located below the converter configuration,
which leads to think that they are converter properties instead of
global settings. What about placing it above the converter list?


Same problem with the Converter Cache option already, isn't it?

Let me propose the attached fix for both at once.


* It would be nice to be able to edit the needauth flag from the
converters settings.


you can already, e.g., browse to the Sweave converters, and you'll see
the needauth option in the extraflags, guess we can edit as well from
the dialog, can't we?


* What happens if a needauth converter is called during instant preview?
Could that happen? And during graphics display?


I've been testing with 2 cases:

1. graphics on-screen conversion & display, used with my (local) gnuplot patch,
   so I insert a .gnuplot image file, and I see its produced output pic on 
screen,
   ..., after a few warnings about running needauth converters :-)...
2. formatted PDF when previewing/rendering PDF

The 1. and 2. cases correspond to 2 different converters call paradigms, one
is from Converters.cpp, the other from GrpahicsConverter.cpp.

AFAIK, instant preview is used for maths, processed through standard (secure) 
latex (no --shell-escape option), what else, what are further calls to 
converters?

Thanks,

T.

>From 8f157f2d3beb48ae87f9dcd07d59ee062a7a7da0 Mon Sep 17 00:00:00 2001
From: Tommaso Cucinotta 
Date: Mon, 28 Nov 2016 00:31:46 +0100
Subject: [PATCH] Converters Prefs UI layout clarification.

---
 src/frontends/qt4/ui/PrefConvertersUi.ui | 28 +---
 1 file changed, 5 insertions(+), 23 deletions(-)

diff --git a/src/frontends/qt4/ui/PrefConvertersUi.ui b/src/frontends/qt4/ui/PrefConvertersUi.ui
index 7e4a1b32..f9c02a86 100644
--- a/src/frontends/qt4/ui/PrefConvertersUi.ui
+++ b/src/frontends/qt4/ui/PrefConvertersUi.ui
@@ -22,7 +22,7 @@

 
  
-  
+  Converter Definitions
  
  
   
@@ -31,7 +31,7 @@
   
6
   
-  
+  

 
  
@@ -43,7 +43,7 @@
 

   
-  
+  

 
  0
@@ -99,7 +99,7 @@
 

   
-  
+  

 
  0
@@ -173,7 +173,7 @@
 

   
-  
+  

 
  0
@@ -225,24 +225,6 @@
 

   
-  
-   
-
- 
-  1
-  5
-  0
-  0
- 
-
-
- Converter Definitions
-
-
- convertersLW
-
-   
-  
  
 

-- 
2.9.3

ctests: invert failing unreliable tests

[Scott Kostyshak]

I think we've had this discussion in part before, but I could not find
the thread.

We are almost at 0 failing tests except for the unreliable tests. I
think we should invert the unreliable tests that are failing, so that
the output from just a vanilla "ctest" command is clean. Since these
tests are unreliable, they might go from failing to passing without
meaning there was a regression, but I still prefer to run 'ctest'
instead of 'ctest -L export'.

When I add a pattern to invertedTests, it does not affect the unreliable
tests. Can we change this?

Attached is the list of unreliable tests that I would like to invert.

Scott
UNRELIABLE.WRONG_OUTPUT_export/doc/de/EmbeddedObjects_pdf4_texF
UNRELIABLE.WRONG_OUTPUT_export/doc/es/Additional_pdf4_texF
UNRELIABLE.ERRATIC_export/doc/es/Customization_pdf4_texF
UNRELIABLE.WRONG_OUTPUT_export/doc/es/EmbeddedObjects_dvi3_texF
UNRELIABLE.WRONG_OUTPUT_export/doc/es/EmbeddedObjects_pdf4_texF
UNRELIABLE.WRONG_OUTPUT_export/doc/es/EmbeddedObjects_pdf5_texF
UNRELIABLE.WRONG_OUTPUT_export/doc/es/UserGuide_dvi3_texF
UNRELIABLE.WRONG_OUTPUT_export/doc/es/UserGuide_pdf4_texF
UNRELIABLE.WRONG_OUTPUT_export/doc/es/UserGuide_pdf5_texF
UNRELIABLE.NONSTANDARD_export/examples/aa_sample_dvi3_texF
UNRELIABLE.NONSTANDARD_export/examples/aa_sample_dvi3_systemF
UNRELIABLE.NONSTANDARD_export/examples/aa_sample_pdf4_texF
UNRELIABLE.NONSTANDARD_export/examples/aa_sample_pdf4_systemF
UNRELIABLE.NONSTANDARD_export/examples/aa_sample_pdf5_texF
UNRELIABLE.NONSTANDARD_export/examples/aa_sample_pdf5_systemF
UNRELIABLE.WRONG_OUTPUT_export/examples/es/linguistics_pdf4_texF
UNRELIABLE.NONSTANDARD_export/examples/fa/splash_dvi
UNRELIABLE.NONSTANDARD_export/examples/fa/splash_dvi3_texF
UNRELIABLE.NONSTANDARD_export/examples/fa/splash_dvi3_systemF
UNRELIABLE.NONSTANDARD_export/examples/fa/splash_pdf
UNRELIABLE.NONSTANDARD_export/examples/fa/splash_pdf2
UNRELIABLE.NONSTANDARD_export/examples/fa/splash_pdf3
UNRELIABLE.NONSTANDARD_export/examples/fa/splash_pdf4_texF
UNRELIABLE.NONSTANDARD_export/examples/fa/splash_pdf4_systemF
UNRELIABLE.NONSTANDARD_export/examples/fa/splash_pdf5_texF
UNRELIABLE.NONSTANDARD_export/examples/fa/splash_pdf5_systemF
UNRELIABLE.NONSTANDARD_export/templates/ACM-siggraph_pdf5_texF
UNRELIABLE.NONSTANDARD_export/templates/ACM-siggraph_pdf5_systemF
UNRELIABLE.NONSTANDARD_export/templates/IUCr-article_pdf4_systemF
UNRELIABLE.NONSTANDARD_export/templates/RJournal_dvi3_systemF
UNRELIABLE.NONSTANDARD_export/templates/RJournal_pdf4_systemF
UNRELIABLE.NONSTANDARD_export/templates/RJournal_pdf5_systemF
UNRELIABLE.NONSTANDARD_export/templates/aa_dvi3_texF
UNRELIABLE.NONSTANDARD_export/templates/aa_dvi3_systemF
UNRELIABLE.NONSTANDARD_export/templates/aa_pdf4_texF
UNRELIABLE.NONSTANDARD_export/templates/aa_pdf4_systemF
UNRELIABLE.NONSTANDARD_export/templates/aa_pdf5_texF
UNRELIABLE.NONSTANDARD_export/templates/aa_pdf5_systemF
UNRELIABLE.NONSTANDARD_export/templates/es_beamer-conference-ornate-20min_pdf4_texF
UNRELIABLE.NONSTANDARD_export/templates/ja_beamer-conference-ornate-20min_pdf2
UNRELIABLE.NONSTANDARD_export/templates/ja_beamer-conference-ornate-20min_pdf4_texF
UNRELIABLE.NONSTANDARD_export/templates/ja_beamer-conference-ornate-20min_pdf4_systemF
UNRELIABLE.NONSTANDARD_export/templates/ja_beamer-conference-ornate-20min_pdf5_texF
UNRELIABLE.NONSTANDARD_export/templates/ja_beamer-conference-ornate-20min_pdf5_systemF
UNRELIABLE.NONSTANDARD_export/templates/kluwer_dvi3_systemF
UNRELIABLE.NONSTANDARD_export/templates/kluwer_pdf4_systemF
UNRELIABLE.NONSTANDARD_export/templates/kluwer_pdf5_systemF


signature.asc
Description: PGP signature

Re: #10481: Hardening LyX against potential misuse

[Scott Kostyshak]

On Sun, Nov 27, 2016 at 01:52:20PM +0100, Guillaume Munch wrote:

> * Converters>Security is located below the converter configuration,
> which leads to think that they are converter properties instead of
> global settings. What about placing it above the converter list?

I noticed this also.

Scott


signature.asc
Description: PGP signature

Re: About LyX web site and wiki site (Was: lyx.org is down again)

[Joel Kulesza]

On Sun, Nov 27, 2016 at 3:54 AM, Christian Ridderström <
christian.ridderst...@gmail.com> wrote:

> On 3 November 2016 at 00:46, Joel Kulesza  wrote:
>
>> On Wed, Nov 2, 2016 at 7:25 AM, Jean-Marc Lasgouttes 
>> wrote:
>>>
>>> If you are interested in updating this part of the wiki, we can give you
>>> the necessary passwords :) Indeed everything is really out of date. The
>>> graphical tour shows proudly LyX 1.3.0pre2!
>>
>>
>> I might be interested... At the risk of raising the ire of
>> traditionalists, as part of reworking some of the parts of the site that
>> have aged less-than-gracefully, I'd be interested to learn more about the
>> infrastructure behind LyX development and distribution to see if moving to
>> more-centralized and/or remotely-hosted solutions make sense.
>>
>
> FYI, both the lyx web site and the wiki site are run by the PmWiki wiki
> engine. The content of both sites can actually be edited through a browser,
> it's simply not as visible for the web site.
>

This is good information.  The wiki would certainly need to be migrated in
its current "wiki" form to that, or another, wiki engine to permit
continued live editing by any personnel.  Given the nature of the websites
design (generally static, no elements requiring dynamic interaction /
database querying) and the current state of markdown languages, I'd be
somewhat inclined to migrate the web presence to inter-linked markdown
files.  The "README" file would then be the "main page".  This will

   1. tightly couple the web information/documentation with the rest of the
   project,
   2. migrate the web information to git,
   3. allow developer contributions to the web presence with equal level of
   permission/authentication that they have to the code (direct push, pull
   request, post patch, etc.).

I've already tried reworking the current README to a markdown-compliant
format and I think it looks better and is more serviceable (i.e., has links
to other appropriate URLs and files).  I think this approach is reasonable
and reduced the barrier to keeping the website up to date and reliance on
few select administrative personnel.  It will also tag/track the website
along with the various releases à la documentation.

If this approach is disagreeable and a more traditional website is
preferred, migrating the website to a standalone git repository seems like
the preferred approach to me.  Because the website is static, the HTML to
control it will be rather basic and should require less wiki-customization
during any future migration.  The only apparent advantage to the current
permission-based wiki format is ease of editing --- am I missing something?


> Regarding "less-than-graceful" ageing, I'm actually surprised they still
> work. And I'm happy people are still editing content on the wiki.   I think
> I started that work over ten years ago, so my memory is a bit vague on the
> details of their configuration...
>

Indeed, the wiki is a nice resource which I've used and contributed to.  As
such, I'd like to see it live on.  One attractive component to me of the
Github/Gitlab services is that they have wiki engines built into projects.
Thus, this is something else I'd like to investigate feasibility of
migrating: existing wiki to Gitlab wiki (following migration testing for
existing Trac to Gitlab issues).

However, if I remember correctly, at the time both the wiki and web site
> where in SVN. Right now it seems only the web site files have a
> .svn/-folder.
>
> But these days we use git, so I don't even know if there's something
> corresponding to the www-user repo in git.
>

 See point above regarding how to migrate the website to git.


> At the time it was possible to checkout the web on a different host, or at
> a different location, and test it there. So when I did bigger configuration
> changes, I deployed and tested locally before putting in production at
> lyx.org.
>

This is my common practice as well.  If I'm working directly on a server, I
work in a ./stg (staging) subdirectory that is live but unknown (this way I
can see how it performs on the actual hardware).  Once migration is
approved to involved parties, the live site goes to ./bak (backup) and
./stg goes to ./.  In this way, the old setup is preserved for some length
of time in case there are issues.

In this migration, because it would (ideally) be moving to a hosted
service, the hosted service site will be built up with content (which is
all slowly changing except the codebase itself). Then, when the hosted
service is set up and ready for migration, pointers will be made from the
current URLs to it with the old site held as "backup" on the server in
Bonn.  This will allow a revert if there are any issues.


> Do you have the login passwords?
>

I do not.  I think there may still be some internal discussion amongst the
developer-admins about what, if any, level of access to grant me to the
various components of the web 

Re: #10481: Hardening LyX against potential misuse

[Guillaume Munch]

Hi Tommaso,


I have been following your work on this issue with interest. Thank you,
this is something that was much needed. Making AppArmor work would be
great too, but I suspect that it is going to be hard to have a
configuration which is both secure and without hassle to the user,
especially since with security there can be no half-measure, and
unrestricted read access can be an issue too. Still any experiment with
it is good. Further comments below.

Le 23/11/2016 à 22:27, Tommaso Cucinotta a écrit :

One note: one way to avoid the [auth session] section growing unbounded,
might be to have an expiry timestamp, so that e.g., authorizations would
expire in ~1y or so. This might be done with a section syntax like:

   

instead of the simple  we have now.


Could that be used to fix #10310 as well?
See https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg195888.html



Any further comment welcome, thanks!



* Please see the attached patch for a few suggestions (more concise, a
few corrections, html formatting, no checkbox). (Using html much
improves readability, but then the html appears in the console output. I
have a solution for this if you choose this route.)

* Please try to avoid lines longer than 80 characters.

* "dangerous, including deleting files": it has been a while that
computer virus are created to do much worse than deleting files...

* Converters>Security is located below the converter configuration,
which leads to think that they are converter properties instead of
global settings. What about placing it above the converter list?

* It would be nice to be able to edit the needauth flag from the
converters settings.

* What happens if a needauth converter is called during instant preview?
Could that happen? And during graphics display?

Thanks again.

Guillaume
diff --git a/src/Converter.cpp b/src/Converter.cpp
index 14b18dd..e596b3d 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -283,29 +283,40 @@ bool Converters::checkAuth(Converter const & conv, string const & doc_fname)
 {
 	if (!conv.need_auth())
 		return true;
-	const docstring security_warning = bformat(_("Requested operation needs use of converter '%1$s' from %2$s to %3$s, "
-		"which is tagged with the 'needauth' option. This is an external program normally acting as a picture/format "
-		"converter, but which is known to be able to execute arbitrary actions on the system on behalf of the user, "
-		"including dangerous ones such as deleting files, if instructed to do so by a maliciously crafted .lyx document."),
-		from_utf8(conv.command()), from_utf8(conv.from()), from_utf8(conv.to()));
+	const docstring security_warning = bformat(
+	  _("The requested operation requires the use of a converter from "
+	"%2$s to %3$s:"
+	"%1$s"
+	"This external program can execute arbitrary commands on your "
+	"system, including dangerous ones, if instructed to do so by a "
+	"maliciously crafted .lyx document."),
+	  from_utf8(conv.command()), from_utf8(conv.from()),
+	  from_utf8(conv.to()));
 	if (lyxrc.use_converter_needauth_forbidden) {
-		frontend::Alert::warning(_("Launch of external converter is forbidden"), security_warning + _("\n\n"
-			"This is forbidden by default. In order to unlock execution of these converters, please, go to\n"
-			"Preferences->File Handling->Converters and uncheck Security->Forbid needauth converters."), true);
+		frontend::Alert::warning(
+		_("An external converter is disabled for security reasons"),
+		security_warning + _(
+		"Your current settings forbid its execution."
+		"(To change this setting, go to Preferences  File "
+		"Handling  Converters and uncheck Security  "
+		"Forbid needauth converters.)"), false);
 		return false;
 	}
 	if (!lyxrc.use_converter_needauth)
 		return true;
-	static const docstring security_title = _("Launch of external converter needs user authorization");
+	static const docstring security_title =
+		_("An external converter requires your authorization");
 	int choice;
-	const docstring security_warning2 = security_warning + _("\n\nWould you like to run the converter?\n\n"
-		"ANSWER RUN ONLY IF YOU TRUST THE ORIGIN/SENDER OF THE LYX DOCUMENT!");
+	const docstring security_warning2 = security_warning +
+		_("Would you like to run this converter?"
+		  "Only run if you trust the origin/sender of the LyX "
+		  "document!");
 	if (!doc_fname.empty()) {
 		LYXERR(Debug::FILES, "looking up: " << doc_fname);
 		std::set & auth_files = theSession().authFiles().authFiles();
 		if (auth_files.find(doc_fname) == auth_files.end()) {
 			choice = frontend::Alert::prompt(security_title, security_warning2,
-0, 0, _("Do  run"), _(""), _(" run for this document"));
+0, 0, _("Do  run"), _(""), _(" run for this document"));
 			if (choice == 2)
 auth_files.insert(doc_fname);
 		} else {
@@ -313,7 +324,7 @@ bool Converters::checkAuth(Converter const & conv, string const & doc_fname)
 		}

Re: #10481: Hardening LyX against potential misuse

[Guillaume Munch]

Le 25/11/2016 à 20:50, Scott Kostyshak a écrit :

On Fri, Nov 25, 2016 at 02:32:37PM -0500, Scott Kostyshak wrote:


I think the line-breaking in the warning dialog should be improved. The
horizontal width is larger than my 13 in. screen. See attached.


Note that the linebreaking on the *other* warning (the Run/ Do Not run)
is fine.


This dialog is custom (GuiToggleWarningDialog). All other messages
dialogs use QMessageBox. GuiToggleWarningDialog is essentially a
QMessageBox::warning with an added checkbox.

Starting from Qt5.2, QMessageBox supports adding a checkbox
(QMessageBox::setCheckBox). I suggest reimplementing
GuiToggleWarningDialog as a QMessageBox, for consistency and to fix the
issue. One will need an #if QT_VERSION >=... directive though.




Also regarding the "first" warning (the "Launch of external converter is
forbidden" warning, which is the one I'm referring to above), although I
have not closely followed the conversation I have the following comment:

I think it should be converted to an error and/or I don't think there
should be a checkbox "Do not show this warning again".


I agree. Note that this also fixes the the line breaking issue since 
QMessageBox is used instead of GuiToggleWarningDialog in that case. (But 
it would still be good to fix GuiToggleWarningDialog.)


Guillaume

About LyX web site and wiki site (Was: lyx.org is down again)

[Christian Ridderström]

Hi Joel,

On 3 November 2016 at 00:46, Joel Kulesza  wrote:

> On Wed, Nov 2, 2016 at 7:25 AM, Jean-Marc Lasgouttes 
> wrote:
>>
>> If you are interested in updating this part of the wiki, we can give you
>> the necessary passwords :) Indeed everything is really out of date. The
>> graphical tour shows proudly LyX 1.3.0pre2!
>
>
> I might be interested... At the risk of raising the ire of
> traditionalists, as part of reworking some of the parts of the site that
> have aged less-than-gracefully, I'd be interested to learn more about the
> infrastructure behind LyX development and distribution to see if moving to
> more-centralized and/or remotely-hosted solutions make sense.
>

FYI, both the lyx web site and the wiki site are run by the PmWiki wiki
engine. The content of both sites can actually be edited through a browser,
it's simply not as visible for the web site.

Regarding "less-than-graceful" ageing, I'm actually surprised they still
work. And I'm happy people are still editing content on the wiki.   I think
I started that work over ten years ago, so my memory is a bit vague on the
details of their configuration...

However, if I remember correctly, at the time both the wiki and web site
where in SVN. Right now it seems only the web site files have a
.svn/-folder.
At the time it was possible to checkout the web on a different host, or at
a different location, and test it there. So when I did bigger configuration
changes, I deployed and tested locally before putting in production at
lyx.org.

But these days we use git, so I don't even know if there's something
corresponding to the www-user repo in git.

Anyway, updating the content of the wiki and the web site ought to
primarily be a matter of using the wiki functionality (for both of them).

Do you have the login passwords?

Regards,
Christian



-- 
Christian Ridderström, +46-70 687 39 44