New Win installer for LyX 2.2.2 available
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
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 Defi&nitions @@ -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 Defi&nitions - - - convertersLW - - - -- 2.9.3
ctests: invert failing unreliable tests
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
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)
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 infrastructure. > Thanks, Joel
Re: #10481: Hardening LyX against potential misuse
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 &NOT run"), _("&Run"), _("&Always run for this document")); +0, 0, _("Do ¬ run"), _("&Run"), _("&Always run for this document")); if (choice == 2) auth_files.insert(doc_fname); } else { @@ -313,7 +324,7 @@ bool Converters::checkAuth(Converter const & conv, s
Re: #10481: Hardening LyX against potential misuse
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)
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