ctests for input encoding
Dear Kornel, the recent discussion about http://www.lyx.org/trac/ticket/10474 showed, that input encoding support was never fully tested. I suggest to extend the tests in autotests/export/latex/Unicode-characters to all encodings defined in lib/encodings. Could you write a rule testing "autotests/export/latex/Unicode-characters/*.lyx" with all encodings (this would also allow to remove the ascii vs. utf8 doubling) or should I place individual files into autotests/export/latex/Unicode-characters/ ? Günter
Re: [patch] remove unsupported encoding l7xenc
On 2016-11-06, Uwe Stöhr wrote: > Am 05.11.2016 um 23:54 schrieb Guenter Milde: >> Inputenc never supported an l7x or l7xenc option. LyX got this wrong >> from the beginning ... > So the fix is simply the attached one. No fileformat change is necessary. Yes, that should do it. > I tested the patch with some Lithuanian texts from the Lithuanian > Wikipedia and it works. Great. IMO, this is should also go to stable. Do you also update the wiki? Then it would make sense to add a remark that not only Unicode fonts, but also the font-encoding L7X solves the problem with drag-and-drop of accented characters from the PDF. In LyX, you can set the font encoding under Document>Settings>Fonts>LaTeX font encoding L7X is supported by LatinModern and the standard Postscript fonts as well as TeXGyre. thanks a lot Günter
Re: Apparmor profile for LyX on Linux ?
Just something concrete to play with, attached. If I run: lyxwrap rm /tmp/whatever it is executed, but if I run: lyxwrap rm /home/tommaso/whatever it says "Permission denied" :-)! So, the idea is to wrap execution of any external converter/plotter/etc., so that they can only write into the /tmp/ folder, except for the case of exporting to .pdf, .tex, etc. Any distro packager on the list with comments? Thanks, T. On 06/11/2016 21:11, Tommaso Cucinotta wrote: Hi all, #10481 is dealing with the problem of making LyX robust to any possible threat arising from maliciously crafted .lyx files that launch unwanted code when viewed on screen and/or converted to PDF/others. The currently provided patch warns the user before launching any converter marked as "needauth". In addition to that, a very good way to deal with the issue seems to give external scripts/converters permissions to write exclusively within /tmp/lyx_tmpdir* temporary folders, this being possible on Linux shipping LyX along with an Apparmor profile (Apparmor is a kind of chroot() on steroids) http://wiki.apparmor.net/index.php/QuickProfileLanguage as nowadays this is widely used by many other programs (just type "find /etc/apparmor.d/"). This would imply to add a usr.bin.lyx file to be installed in /etc/apparmor.d/ on Linux only. Before working out a first try, I'd like to hear comments from others, especially on the side of portability (Mac/Win users). From a quick search, it seems the Mac OS-X way for the same thing would be using TrustedBSD: http://sysdev.me/trusted-bsd-in-osx/ Any comment welcome, thanks! T. commit 0eb1417d Author: Tommaso Cucinotta Date: Mon Nov 7 00:39:33 2016 +0100 Added lyxwrap wrapper along with apparmor.d script for safe execution of external converters. diff --git a/configure.ac b/configure.ac index 05e73285..773fe002 100644 --- a/configure.ac +++ b/configure.ac @@ -387,6 +387,7 @@ AC_CONFIG_FILES([Makefile \ development/lyx.spec \ lib/lyx.desktop-temp:lib/lyx.desktop.in lib/Makefile \ + lib/usr.bin.lyxwrap \ lib/doc/Makefile \ lib/lyx2lyx/lyx2lyx_version.py \ lib/lyx2lyx/Makefile \ diff --git a/lib/Makefile.am b/lib/Makefile.am index a19d4f2c..4b2fedf6 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -2485,6 +2485,9 @@ install-data-hook: chmod 644 "$(DESTDIR)$(pkgdatadir)/$$i"; \ fi; \ done +if INSTALL_POSIX + cp usr.bin.lyxwrap /etc/apparmor.d/ +endif alltests: check alltests-recursive diff --git a/lib/usr.bin.lyxwrap.in b/lib/usr.bin.lyxwrap.in new file mode 100644 index ..dd990d25 --- /dev/null +++ b/lib/usr.bin.lyxwrap.in @@ -0,0 +1,15 @@ +# vim:syntax=apparmor +# Author: Tommaso Cucinotta + +#include + +@prefix@/bin/lyxwrap { + /tmp/** ixrw, + @{HOME}/** ixr, + / ixr, + /** ixr, + deny /etc/security/ xrw, + deny /etc/security/** xrw, + deny /etc/passwd* xrw, + deny /etc/shadow* xrw, +} diff --git a/src/Makefile.am b/src/Makefile.am index 8ac13067..4e51ba5b 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -25,7 +25,7 @@ OTHERLIBS = $(BOOST_LIBS) $(MYTHES_LIBS) $(ENCHANT_LIBS) $(HUNSPELL_LIBS) \ $(LIBSHLWAPI) $(LIBPSAPI) noinst_LIBRARIES = liblyxcore.a -bin_PROGRAMS = lyx +bin_PROGRAMS = lyx lyxwrap lyx_LDADD = \ liblyxcore.a \ @@ -100,6 +100,9 @@ if LYX_WIN_RESOURCE lyx_SOURCES += lyxwinres.rc endif +lyxwrap_SOURCES = \ + lyxwrap.cpp + SOURCEFILESCORE = \ Author.cpp \ boost.cpp \
Re: #10481: Hardening LyX against potential misuse
On 07/11/2016 00:19, Richard Heck wrote: Questions: We're not supposed just to use "Yes" and "No", right? still missing the global option to suppress any questions (assume always yes or always no), and, I think also the persisting the chosen yes/no to disk (where? any hint? what about $HOME/.lyx/auth-files.txt containing a simple list of abs filenames where the user said "yes, and don't ask for this doc" ?) This changes the format of some file or other. Which one? Is this a format change in the relevant sense of "master only"? there's a new option among the flags/options of converters, without file format change; new shipped format would have those additional "needauth" flags set on known potentially harmful converters. + static const char securityWarning[] = This can just be a string yes? I don't think we usually use char[]. I'm ok with anything, is there a usual place where to place a shared string across 2 modules, like this? (noticed it got twice into the final lyx executable, perhaps as I'm compiling debug-mode) Thanks, T.
Re: #10481: Hardening LyX against potential misuse
Questions: We're not supposed just to use "Yes" and "No", right? This changes the format of some file or other. Which one? Is this a format change in the relevant sense of "master only"? > diff --git a/src/Converter.cpp b/src/Converter.cpp > index 58e486e6..02631ca4 100644 > --- a/src/Converter.cpp > +++ b/src/Converter.cpp > > + if (conv.need_auth()) { > + static const char securityWarning[] = This can just be a string yes? I don't think we usually use char[]. > diff --git a/src/graphics/GraphicsConverter.cpp > b/src/graphics/GraphicsConverter.cpp > index 67b1580f..6017073f 100644 > --- a/src/graphics/GraphicsConverter.cpp > +++ b/src/graphics/GraphicsConverter.cpp > @@ -15,6 +15,7 @@ > #include "Converter.h" > #include "Format.h" > > +#include "frontends/alert.h" > #include "support/lassert.h" > #include "support/convert.h" > #include "support/debug.h" > @@ -372,6 +373,15 @@ static void build_script(string const & from_file, > outfile = tempfile.name().toFilesystemEncoding(); > } > > + if (conv.need_auth()) { > + static const char securityWarning[] = Same here? Richard
caption text for image not justify
Dear lyx team thank you for your job, support, creativity. I got samll problem in the caption text of image, it's not justify. please see the image in attachment files. best regards caption.lyx Description: application/lyx caption.pdf Description: Adobe PDF document
Apparmor profile for LyX on Linux ?
Hi all, #10481 is dealing with the problem of making LyX robust to any possible threat arising from maliciously crafted .lyx files that launch unwanted code when viewed on screen and/or converted to PDF/others. The currently provided patch warns the user before launching any converter marked as "needauth". In addition to that, a very good way to deal with the issue seems to give external scripts/converters permissions to write exclusively within /tmp/lyx_tmpdir* temporary folders, this being possible on Linux shipping LyX along with an Apparmor profile (Apparmor is a kind of chroot() on steroids) http://wiki.apparmor.net/index.php/QuickProfileLanguage as nowadays this is widely used by many other programs (just type "find /etc/apparmor.d/"). This would imply to add a usr.bin.lyx file to be installed in /etc/apparmor.d/ on Linux only. Before working out a first try, I'd like to hear comments from others, especially on the side of portability (Mac/Win users). From a quick search, it seems the Mac OS-X way for the same thing would be using TrustedBSD: http://sysdev.me/trusted-bsd-in-osx/ Any comment welcome, thanks! T.
Re: #10481: Hardening LyX against potential misuse
last patch attached. T. On 06/11/2016 20:56, LyX Ticket Tracker wrote: #10481: Hardening LyX against potential misuse -+-- Reporter: t.cucinotta | Owner: lasgouttes Type: enhancement | Status: new Priority: highest | Milestone: Component: general | Version: unspecified Severity: major| Resolution: Keywords: | -+-- Comment (by t.cucinotta): Just fixed minor things and the wording in the attached .2.patch file, however there's the major issue that in GraphicsConverter there's no info whatsoever about buffer name, so it won't be possible to have the "yes, don't ask for the doc" option in that case, that case being display on-screen, which is probably the most common/needed (the one that works ok is when you export to PDF or other formats). Tried to add the missing context in a separate patch, but got to nothing but ... segfaults! commit c5c02d37 Author: Tommaso Cucinotta Date: Sat Nov 5 01:00:44 2016 +0100 Add needauth option to converters that need explicit user authorization before being run. Addressing #10481. Converters marked with the new "needauth" option won't be run unless the user gives explicit authorization, which is asked on-demand when the converter is about to be run (question is not asked if the file is cached and the converter is not needed). The user prompt has a 3rd button (yes to all for document) so that he/she's not prompted again for the same converter over the same document (identified through buffer->filePath()). diff --git a/lib/configure.py b/lib/configure.py index 09d053e9..705aed6c 100644 --- a/lib/configure.py +++ b/lib/configure.py @@ -749,8 +749,8 @@ def checkConverterEntries(): rc_entry = [r'''\converter latex lyx"%% -f $$i $$o" "" \converter latexclipboard lyx"%% -fixedenc utf8 -f $$i $$o" "" \converter literate lyx"%% -n -m noweb -f $$i $$o" "" -\converter sweave lyx"%% -n -m sweave -f $$i $$o" "" -\converter knitr lyx"%% -n -m knitr -f $$i $$o" ""'''], not_found = 'tex2lyx') +\converter sweave lyx"%% -n -m sweave -f $$i $$o" "needauth" +\converter knitr lyx"%% -n -m knitr -f $$i $$o" "needauth"'''], not_found = 'tex2lyx') if path == '': logger.warning("Failed to find tex2lyx on your system.") @@ -763,24 +763,24 @@ def checkConverterEntries(): \converter literate dviluatex "%%" ""''']) # checkProg('a Sweave -> LaTeX converter', ['Rscript --verbose --no-save --no-restore $$s/scripts/lyxsweave.R $$p$$i $$p$$o $$e $$r'], -rc_entry = [r'''\converter sweave latex "%%" "" -\converter sweave pdflatex "%%" "" -\converter sweave xetex "%%" "" -\converter sweave luatex "%%" "" -\converter sweave dviluatex "%%" ""''']) +rc_entry = [r'''\converter sweave latex "%%" "needauth" +\converter sweave pdflatex "%%" "needauth" +\converter sweave xetex "%%" "needauth" +\converter sweave luatex "%%" "needauth" +\converter sweave dviluatex "%%" "needauth"''']) # checkProg('a knitr -> LaTeX converter', ['Rscript --verbose --no-save --no-restore $$s/scripts/lyxknitr.R $$p$$i $$p$$o $$e $$r'], -rc_entry = [r'''\converter knitr latex "%%" "" -\converter knitr pdflatex "%%" "" -\converter knitr xetex "%%" "" -\converter knitr luatex "%%" "" -\converter knitr dviluatex "%%" ""''']) +rc_entry = [r'''\converter knitr latex "%%" "needauth" +\converter knitr pdflatex "%%" "needauth" +\converter knitr xetex "%%" "needauth" +\converter knitr luatex "%%" "needauth" +\converter knitr dviluatex "%%" "needauth"''']) # checkProg('a Sweave -> R/S code converter', ['Rscript --verbose --no-save --no-restore $$s/scripts/lyxstangle.R $$i $$e $$r'], -rc_entry = [ r'\converter sweave r "%%"""' ]) +rc_entry = [ r'\converter sweave r "%%""needauth"' ]) # checkProg('a knitr -> R/S code converter', ['Rscript --verbose --no-save --no-restore $$s/scripts/lyxknitr.R $$p$$i $$p$$o $$e $$r tangle'], -rc_entry = [ r'\converter knitr r "%%"""' ]) +rc_entry = [ r'\converter knitr r "%%""needauth"' ]) # checkProg('an HTML -> LaTeX converter', ['html2latex $$i', 'gnuhtml2latex', 'htmltolatex -input $$i -output $$o', 'htmltolatex.jar -input $$i -output $$o'], diff --git a/src/Converter.cpp b/src/Converter.cpp index 58e486e6..02631ca4 100644 --- a/src/Converter.cpp +++ b/src/Converter.cpp @@ -100,7 +100,7 @@ Converter::Converter(string const & f, string const & t, string const & c, string const & l) : from_(f), to_(t), command_(c), flags_(l), From_(0), To_(0), latex_(false), xml_(fals
Re: [patch] remove unsupported encoding l7xenc
Am 05.11.2016 um 23:54 schrieb Guenter Milde: Inputenc never supported an l7x or l7xenc option. LyX got this wrong from the beginning Tanks, now I got it. So the fix is simply the attached one. No fileformat change is necessary. I tested the patch with some Lithuanian texts from the Lithuanian Wikipedia and it works. thanks and regards Uwe lib/encodings | 3 +-- lib/languages | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/lib/encodings b/lib/encodings index 75ae8f3..47c23cf 100644 --- a/lib/encodings +++ b/lib/encodings @@ -69,8 +69,7 @@ End Encoding iso8859-9 latin5 "Turkish (ISO 8859-9)" ISO-8859-9 fixed inputenc End -# Not standard, see http://www.vtex.lt/tex/littex/index.html -Encoding iso8859-13 l7xenc "Baltic (ISO 8859-13)" ISO-8859-13 fixed inputenc +Encoding iso8859-13 latin7 "Baltic (ISO 8859-13)" ISO-8859-13 fixed inputenc End Encoding iso8859-15 latin9 "Western European (ISO 8859-15)" ISO-8859-15 fixed inputenc diff --git a/lib/languages b/lib/languages index 53d5feb..4433738 100644 --- a/lib/languages +++ b/lib/languages @@ -800,7 +800,7 @@ Language lithuanian BabelNamelithuanian PolyglossiaName lithuanian QuoteStyle german - Encoding iso8859-4 + Encoding iso8859-13 FontEncoding L7x LangCode lt_LT AsBabelOptions true
Re: pasted non-acceptable symbol
Am 06.11.2016 um 14:30 schrieb Jean-Marc Lasgouttes : > > Le 05/11/2016 à 21:25, Stephan Witt a écrit : >>> 4/ catch the characters at the level of the row breaking algorithm >>> (TextMetrics::breakRow). This should be pretty straightforward to do. >> >> Yes, this would be the best solution. It seems so easy that I tried to >> come up with a patch myself. See attached. It works for this problem - >> I don’t know if its covers all possible code paths, though. > > This is a more radical approach that what I have in mind, and I do not know > whether it is safe. My idea was to modify the Row building code and replace > the character with some visual cue (in addition with the row breaking), > because I am not confident in sending this character to Qt string rendering > functions. > > I'll propose something shortly. Ok, Stephan
Re: [patch] On-screen justification: stretch in proportion with the em, up to a limit
OK. JMarc Le 6 novembre 2016 16:33:09 GMT+01:00, Guillaume Munch a écrit : > >Most of the times it is already clear from the other lines that the >text >is justified. In addition, on-screen justification cannot be much more >than cosmetic anyway, since there is an option to disable it. The goal >is to increase readability, and additional clues would only clutter, in > >my opinion.
Re: [patch] On-screen justification: stretch in proportion with the em, up to a limit
Le 06/11/2016 à 16:11, Jean-Marc Lasgouttes a écrit : Something I meant to mention: shall we add some on screen cue that the row has not been completely stretched ? JMarc Most of the times it is already clear from the other lines that the text is justified. In addition, on-screen justification cannot be much more than cosmetic anyway, since there is an option to disable it. The goal is to increase readability, and additional clues would only clutter, in my opinion.
Re: [patch] On-screen justification: stretch in proportion with the em, up to a limit
Something I meant to mention: shall we add some on screen cue that the row has not been completely stretched ? JMarc Le 6 novembre 2016 14:57:30 GMT+01:00, Guillaume Munch a écrit : >Le 29/08/2016 à 14:16, Jean-Marc Lasgouttes a écrit : >> >> The patch looks good. > >It's in at b30f8d3c4b
Re: Shutdown bug?
> On 6 Nov 2016, at 12:32, Stephan Witt wrote: > >> Am 06.11.2016 um 13:21 schrieb Paola Manzini : >> >> Hi All, >> >> I am running LyX on mac OS Sierra on a macbook pro, and El Capitan on an >> iMAc, and I’ve noticed the following bug, both with 2.2.0 and 2.2.2 on the >> Sierra machine, and 2.2.2 on the El Capitan machine: whenever I try to >> either open a file from any directory on my hard disk, or save a new file >> (or save as, requiring a change in filename), the command succeeds, but at >> the same time I get a pop up “bug” message, and lyx shuts down, see >> screenshot. > > Hi Paola, > > I’m sorry for that - but I cannot reproduce this problem on my system (El > Capitan and LyX 2.2.2 or LyX 2.3.x development). > Unfortunately the crash report you’ve posted is not helpful. > > Do have the problem with all LyX documents or not? > > Regards, > Stephan > Dear Stephan, yes I do have the same issue with all files, and on both machines. It is an inconvenience, but it does not prevent me from working, though. I did wonder whether this was my problem only. Many thanks, Paola
Re: [patch] On-screen justification: stretch in proportion with the em, up to a limit
Le 29/08/2016 à 14:16, Jean-Marc Lasgouttes a écrit : The patch looks good. It's in at b30f8d3c4b
Re: pasted non-acceptable symbol
Le 05/11/2016 à 21:25, Stephan Witt a écrit : 4/ catch the characters at the level of the row breaking algorithm (TextMetrics::breakRow). This should be pretty straightforward to do. Yes, this would be the best solution. It seems so easy that I tried to come up with a patch myself. See attached. It works for this problem - I don’t know if its covers all possible code paths, though. This is a more radical approach that what I have in mind, and I do not know whether it is safe. My idea was to modify the Row building code and replace the character with some visual cue (in addition with the row breaking), because I am not confident in sending this character to Qt string rendering functions. I'll propose something shortly. JMarc
Re: pasted non-acceptable symbol
Le 06/11/2016 à 13:25, Stephan Witt a écrit : After doing some code analysis and thinking again I came to the conclusion that my patch is not the best one. One shouldn’t handle U+2028 and U+2029 the same way. To treat LINE SEPARATOR as a new line is ok, IMO. The PARAGRAPH SEPARATOR needs a different handling and makes more work. First it shouldn’t go in as is when pasting text. Probably the LyX file parser can handle the case when the LX file somehow contains a U+2029 already. This patch is orthogonal to the other one. I am not sure that you want to do it in real paste (i.e. when pasting LyX text to LyX text), but rather in the insertStringAs(Lines/Paragraphs) methods, when the two unicode characters should be interpreted as needed. Moreover I do not think it is interesting to add a new method in textutils.h for testing a single character. The convention we use now is like: static char_type const thin = 0x2009; // U+2009 THIN SPACE directly at the place of the source where you use it. JMarc
Re: Shutdown bug?
Am 06.11.2016 um 13:21 schrieb Paola Manzini : > > Hi All, > > I am running LyX on mac OS Sierra on a macbook pro, and El Capitan on an > iMAc, and I’ve noticed the following bug, both with 2.2.0 and 2.2.2 on the > Sierra machine, and 2.2.2 on the El Capitan machine: whenever I try to either > open a file from any directory on my hard disk, or save a new file (or save > as, requiring a change in filename), the command succeeds, but at the same > time I get a pop up “bug” message, and lyx shuts down, see screenshot. Hi Paola, I’m sorry for that - but I cannot reproduce this problem on my system (El Capitan and LyX 2.2.2 or LyX 2.3.x development). Unfortunately the crash report you’ve posted is not helpful. Do have the problem with all LyX documents or not? Regards, Stephan
Re: pasted non-acceptable symbol
Am 05.11.2016 um 21:25 schrieb Stephan Witt : > > Am 05.11.2016 um 16:31 schrieb Jean-Marc Lasgouttes : >> >> Le 05/11/2016 à 13:30, Jean-Marc Lasgouttes a écrit : >>> OK, I can reproduce it now. The problem is with characters >>> LINE SEPARATOR (U+2028) >>> PARAGRAPH SEPARATOR (U+2029) >>> >>> Since they break line/character in string display, we get "interesting" >>> consequences when trying to move cursor. It should not be difficult to >>> avoid the crash, but the result will not be satisfactory. I see two >>> possibilities: >>> >>> 1/ replace them with proper line-break or paragraph-break on import >>> from Unicode text. This is not 100% fail-safe, but it be easy and >>> help in many cases. >>> >>> 2/ keep them but interpret them as space everywhere for display. This >>> will not give the same as PDF output, I guess >>> >>> 3/ find a way to replace them with proper line/paragraph breaks in our >>> document seamlessly. This seems a bit difficult to achieve, actually. >> >> Or; >> >> 4/ catch the characters at the level of the row breaking algorithm >> (TextMetrics::breakRow). This should be pretty straightforward to do. >> >> JMarc >> > > Yes, this would be the best solution. It seems so easy that I tried to > come up with a patch myself. See attached. It works for this problem - > I don’t know if its covers all possible code paths, though. After doing some code analysis and thinking again I came to the conclusion that my patch is not the best one. One shouldn’t handle U+2028 and U+2029 the same way. To treat LINE SEPARATOR as a new line is ok, IMO. The PARAGRAPH SEPARATOR needs a different handling and makes more work. First it shouldn’t go in as is when pasting text. Probably the LyX file parser can handle the case when the LX file somehow contains a U+2029 already. What do you think? Is it possible to test for U+2029 this way? I attach the updated patch without the file parser change. I didn’t do this yet. Stephan lineForTextPosition-4-crash.patch Description: Binary data
Re: loset my cocnut in lyx
Dear Richard, Joel Thank you for your supported. Best regards بتاريخ ٠٤/١١/٢٠١٦ ٧:٣٥ م، كتب "Joel Kulesza" : > On Fri, Nov 4, 2016 at 9:41 AM, Richard Heck wrote: > >> Practically speaking, you're probably best off exporting the svg to png >> and using that in the LyX file. > > > I tested exporting the SVG to PDF with Inkscape, and all coconuts are > present, accounted for, and in vector form. This might be another option. > That said, I was able to render SVG using pdflatex. > >
Re: Inverted colors for cursor
On 22.10.2016 14:38, Joel Kulesza wrote: Interesting, yes, the options are different when that checkbox is selected (I would have expected them to remain the same but be overridden by the system colors). Furthermore, unchecking that box (which is checked, by default, I believe), permits me to change colors for items like the shaded box (that I reported on in Ticket 10420). I will update the ticket with a suggestion to "grey out" the color box when System Colors is checked. This should direct users to the right place and/or right option to enable/disable. I think your ticket was "removed" without the greyed out suggestion being appreciated. I have added a new ticket and a patch for it. http://www.lyx.org/trac/ticket/10483 Let's see whether it finds supporters apart from you and me. :) Daniel