Re: Copying translations from 2.2.x to master?
On Wed, Jul 05, 2017 at 01:50:19AM +0200, Uwe Stöhr wrote: > The translations can be done. I stored all changes I made at the usual > changelog files in the docs folder. Thanks, Uwe! I sent the email for translations and asked them to finish within two weeks. Scott signature.asc Description: PGP signature
Update on beta1 status and blockers
Dear all, We have three current beta blockers (see the corresponding footnotes for the current status of each): - the minted issue [1] - the dash issue [2] - translations [3] Please let me know if you view any other issue as a beta blocker. In the mean time, if you are looking for something to do, it would be great if you can take a look at the list of bugs targeted to 2.3 [4]. Even if you can't fix them, your help in triaging them, trying to reproduce them, and thoughts on whether any should be delayed, would be appreciated. Scott [1] https://www.mail-archive.com/search?l=mid&q=20170705045915.h4uyrsc27g54da3m%40steph [2] https://www.mail-archive.com/search?l=mid&q=20170614180850.zox3c3smetjzh677%40steph [3] https://www.mail-archive.com/search?l=mid&q=20170704235019.6160467.86841.11050%40web.de [4] http://www.lyx.org/trac/query?status=accepted&status=assigned&status=new&status=reopened&description=~&milestone=2.3.0&summary=~&reporter=~&col=id&col=summary&col=reporter&col=status&col=type&col=severity&col=keywords&desc=1&order=id signature.asc Description: PGP signature
Options for resolving the minted + shell-escape issue
Dear all,
This is an important topic since it involves security. I'd appreciate it
if you spent some time on understanding the issue.
I see three options for what to do about the minted + shell-escape
issue:
1. Revert the recently added minted support.
2. Keep the current state of master.
3. Apply the patch at [1] (also attached for convenience).
We do not have unanimous agreement on what to do and I would like to
have a vote, since this topic involves security.
Another relevant piece of news is that the minted author is interested
in making it so -shell-escape is not needed [2]. That work could be done
in minted within a few months (see the Github issue for details), and
perhaps we could incorporate this into LyX 2.4.0.
For more background, see the mega-thread at [3]. See, in particular, the
useful summary from Guillaume's perspective at [4].
I can see reasonable arguments for all three options. When voting, I ask
you to focus specifically on the issue of security. Although adding
minted support is a nice feature, if we think it will decrease security,
we should not do it. The question I focus on when deciding which option
I think is best is "with which option is the average user least likely
to end up running malicious code"?
Scott
[1]
https://www.mail-archive.com/search?l=mid&q=20170620203439.GC1008%40GIOVE
[2]
https://github.com/gpoore/minted/issues/166
[3]
https://www.mail-archive.com/search?l=mid&q=20170529215308.ojd3b42tkyqmnl4l%40steph
[4]
https://www.mail-archive.com/search?l=mid&q=oi9r49%24hn2%241%40blaine.gmane.org
diff --git a/src/Converter.cpp b/src/Converter.cpp
index 6e10b18704..45b725e8c6 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -19,14 +19,18 @@
#include "Encoding.h"
#include "ErrorList.h"
#include "Format.h"
+#include "InsetList.h"
#include "Language.h"
#include "LaTeX.h"
#include "LyXRC.h"
#include "Mover.h"
+#include "ParagraphList.h"
#include "Session.h"
#include "frontends/alert.h"
+#include "insets/InsetInclude.h"
+
#include "support/debug.h"
#include "support/FileNameList.h"
#include "support/filetools.h"
@@ -279,20 +283,38 @@ OutputParams::FLAVOR
Converters::getFlavor(Graph::EdgePath const & path,
}
-bool Converters::checkAuth(Converter const & conv, string const & doc_fname)
+bool Converters::checkAuth(Converter const & conv, string const & doc_fname,
+ bool use_shell_escape)
{
- if (!conv.need_auth())
+ if (!conv.latex())
+ use_shell_escape = false;
+ if (!conv.need_auth() && !use_shell_escape)
return true;
- const docstring security_warning = bformat(
- _("The requested operation requires the use of a converter
from "
- "%2$s to %3$s:"
+ string conv_command = conv.command();
+ bool const has_shell_escape = contains(conv_command, "-shell-escape");
+ size_t const token_pos = conv_command.find("$$");
+ bool const has_token = token_pos != string::npos;
+ string const command = use_shell_escape && !has_shell_escape
+ ? (has_token ? conv_command.insert(token_pos, "-shell-escape ")
+: conv_command.append(" -shell-escape"))
+ : conv_command;
+ docstring const security_warning = (use_shell_escape
+ ? bformat(_("This document uses minted listings, so the LaTeX "
+ "backend needs to be able to launch external programs:"
+ "%1$s"
+ "The external programs can execute arbitrary commands on "
+ "your system, including dangerous ones, if instructed to do "
+ "so by a maliciously crafted LyX document."),
+ from_utf8(command))
+ : 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) {
+ "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(command), from_utf8(conv.from()),
+ from_utf8(conv.to(;
+ if (lyxrc.use_converter_needauth_forbidden && !use_shell_escape) {
frontend::Alert::error(
_("An external converter is disabled for security reasons"),
security_warning + _(
@@ -302,29 +324,43 @@ bool Converters::checkAuth(Converter const & conv, string
const & doc_fname)
"Forbid needauth converters.)"), false);
return false;
Re: Can shell-escape take advantage of needauth framework?
On Wed, Jun 28, 2017 at 02:36:49PM +0200, Guillaume MM wrote: > Le 27/06/2017 à 23:45, Tommaso Cucinotta a écrit : > > > > 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. > > This is also what I remember. The now secured converters were sweave and > knitr, introduced in 2011 and 2012. +1 > I see that you have also introduced a gnuplot converter with an example. > > + Proportionality: unsafety is actually a main feature of gnuplot from > what I understand from http://www.yqcomputer.com/320_2475_1.htm > + Specificity: only gnuplot is given elevated privileges, which is what > the user wants. > - UI problem 1: When I open the example, I immediately get the needauth > dialog for showing the preview. I thought we only wanted unsafe > execution when compiling the document. I forget what we decided on this. If we don't give the dialog, then we should just disable the preview? > It seems to me that needauth, as it is, is not ready for the addition of > gnuplot. What do you think? I'm not sure. Is it less secure than Sweave/knitr? Or is your argument that those were already there so needauth makes them safer, but we should not add any other converter that needs needauth? Scott signature.asc Description: PGP signature
Re: Can shell-escape take advantage of needauth framework?
On Tue, Jun 27, 2017 at 09:26:30PM +0200, Enrico Forestieri wrote: > I don't think that reverting is in discussion here It is as long as even one LyX developer proposes it. Scott signature.asc Description: PGP signature
Re: Can shell-escape take advantage of needauth framework?
On Wed, Jun 28, 2017 at 02:37:41PM +0200, Guillaume MM wrote: > Le 27/06/2017 à 21:00, Scott Kostyshak a écrit : > > > > 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 in favour of treating lyx users like adults. To me, this means not > reinventing the wheel and follow established guidelines. See e.g. > > https://developer.apple.com/library/content/documentation/Security/Conceptual/SecureCodingGuide/Articles/AppInterfaces.html > > and the paper they mention which has a lot of examples. That's a great article. Thanks for the link. I've thought about a lot of the principles mentioned in the article in the context of each of what I view as the three options for moving forward: 1. Revert the recently added minted support. 2. Keep the current state of master. 3. Apply the patch from [1]. Below, I will refer to these three options by their numbers above, e.g. (1), (2), and (3). Of course, the quotes I choose and my analysis of whether each option "passes" or "fails" a criterion are completely subjective. Starting at the section <> "In many cases, a simpler interface is more secure, because the user is less likely to ignore security features and less likely to make mistakes." (1) fails: implementing minted through custom preamble code and ERT is not simple (2) at least the user only needs to do the "shell-escape dance", which is what I refer to going to Tools > Preferences > File Handling > Converters, adding "-shell-escape" (remembering whether "shell-escape" is preceded by one dash or two dashes), clicking "Modify", and then finally clicking "Apply" or "Save" (which I believe is a separate source of confusion for the users). (3) passes: it is simple to read the dialog and click on the button. Moving on to the section <> "The user must be made aware of when they are granting authorization to some entity to act on their behalf or to gain access to their files or data." (1) fails: when the user does the "shell-escape dance" they are not given any dialog making them aware of the potential dangers. You might think "well they are adding it themselves so they should already know", but I would say that most users are probably following some unofficial guide they saw on the internet and just copy/pasting stuff in without thinking. (2) same as (1) (3) passes: there is a dialog with an explanation. "In this case, sharing should be off by default." (1) - (3) all pass. "If the user turns it on, the interface should make clear the extent to which remote users can read from and write to files on the local system." (1) fails: there is no dialog. (2) fails: no dialog (3) passes "In addition, as long as sharing is on, there should be some clear indication that it is on, lest users forget that their files are accessible by others." (this was also brought up by Guillaume at [2]) (1) - (3) all fail. I think that (3) has the most potential for implementing a visual indication, unless we want to parse the converter command for "shell-escape". "Authorization should be revocable" (1) passes (2) passes (3) fails: if the user puts "Always allow for this document", it is not easy to revoke. The user must know something about the sessions file, which they should not be expected to know. We could put instructions for how to remove access. I'm not sure if I agree with adding even more text to the dialog though. Tommaso mentioned some ideas regarding revocation in the context of needauth at [3]. "Whenever possible, your program should not only make this possible, it should make it easy to do." (1) - (2) fail because of the "shell-escape dance" and (3) fails because of the sessions file. "You should also make it clear that revoking authorization cannot reverse damage already done" I don't understand this. In our case would this mean that if the user removes "shell-escape" we give a dialog saying "the previous compilations you did with this compiler could have run malicious code" ? If so, I think that might confuse users more than benefit them. Moving on to the section <> Not much to talk about here. (3) does work as I expected when I tested on the command line. Moving on to the section <> I think that (1) - (3) all fail this. Preferences and sessions files are stored in plain text that can be easily edited. I think we could improve this by storing them somewhere else where the user doesn't have permissions, but I suppose we will always want to allow the user to edit their preferences with an external editor, and backup/restore preferences files. So I'm not sure if there's a feasible way to address this. I think that (3) fails this a little more than the others, because the sessions file is one more
Re: Copying translations from 2.2.x to master?
The translations can be done. I stored all changes I made at the usual changelog files in the docs folder. Original Message From: Scott Kostyshak Sent: Mittwoch, 5. Juli 2017 00:04 To: lyx-devel@lists.lyx.org; Uwe Stöhr Cc: Jean-Pierre Chrétien Subject: Re: Copying translations from 2.2.x to master? On Fri, Jun 30, 2017 at 11:15:29PM -0400, Scott Kostyshak wrote: > Uwe, I am going to send an email to the translators. My big question to > you (or anyone else) is: am I supposed to wait for the docs to be > prepared before sending the email so that the translators can work on > translating the docs at the same time as the strings? Or since our > strings are ready can I send the email now? I would like to send the > email as soon as possible so that we can start the clock on getting > beta1 out. Jean-Pierre, I think Uwe may be too busy to respond to the above for a while. Do you know the answer? In the past, have translators been notified after strings are ready but before the documentation is ready? Or did we instead wait for the documentation is ready? Thanks, Scott
Re: Copying translations from 2.2.x to master?
On Fri, Jun 30, 2017 at 11:15:29PM -0400, Scott Kostyshak wrote: > Uwe, I am going to send an email to the translators. My big question to > you (or anyone else) is: am I supposed to wait for the docs to be > prepared before sending the email so that the translators can work on > translating the docs at the same time as the strings? Or since our > strings are ready can I send the email now? I would like to send the > email as soon as possible so that we can start the clock on getting > beta1 out. Jean-Pierre, I think Uwe may be too busy to respond to the above for a while. Do you know the answer? In the past, have translators been notified after strings are ready but before the documentation is ready? Or did we instead wait for the documentation is ready? Thanks, Scott signature.asc Description: PGP signature
Re: ext_copy.py
On Tue, Jul 04, 2017 at 11:33:02AM +0100, José Abílio Matos wrote: > On Saturday, 1 July 2017 04.54.15 WEST Scott Kostyshak wrote: > > Pinging José. > > > > Scott > > I am sorry for the huge latency time but I have been busy with exams & Co. > That period is now over. No problem at all. I hope you don't mind my nagging emails (if you do, please say so). > Is it OK then to apply the patch? Yes, please. Thanks, Scott signature.asc Description: PGP signature
fonts provided by lyx
Hi, According to "ReadmeBaKoMa4LyX.txt" and "BaKoMaFontLicense.txt" in the lib/fonts directory the included fonts are meant for Windows. Does this mean they are not necessary for linux? Thanks, Cor
Re: ext_copy.py
On Saturday, 1 July 2017 04.54.15 WEST Scott Kostyshak wrote: > Pinging José. > > Scott I am sorry for the huge latency time but I have been busy with exams & Co. That period is now over. Is it OK then to apply the patch? Regards, -- José Abílio
Re: Document output format PDF(LuaTeX) .. instant preview of math
Am Freitag, 9. Dezember 2016 um 19:38:59, schrieb Kornel Benko > Am Freitag, 9. Dezember 2016 um 19:21:04, schrieb Kornel Benko > > > Am Freitag, 9. Dezember 2016 um 18:48:57, schrieb Enrico Forestieri > > > > > On Fri, Dec 09, 2016 at 02:36:04PM +0100, Kornel Benko wrote: > > > > > > > > Nobody seems interested. Probably no one uses PDF(luatex) as default > > > > output > > > > format. > > > > > > Or, more simply, don't experience the issue. See attached. > > > > > > > Do you use the latest TL2016? I did not see it with TL2015 too. > > Yes, just retested with TL2015. Looks good. > Lualatex at TL2017 is OK too. Kornel signature.asc Description: This is a digitally signed message part.
