Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
Hi again, Am 07.03.21 um 23:08 schrieb Rene Engelhard: > Am 07.03.21 um 22:45 schrieb Milko Krachounov: >> After some additional testing, checking my environment and inspecting pyuno/ >> source/loader/pyuno_loader.cxx, I want to amend the report, particularly >> about >> 7.0.4 which is not affected (kind of). > > Interestingly, in discussion on #debian-devel it is said that it does :/ > > See below. [...] OK, some more discussion sheds some more light on it and would explain it. From #debian-devel again: 23:10 < _jwilk> OK, I kinda reproduced in buster without setting PYTHONPATH myself. It doesn't crash for me, but it can't open the CSV file. 23:11 < _jwilk> I had to install libreoffice-lightproof-pt-br to trigger the bug. 23:13 < _jwilk> So, yay, mystery solved? 23:14 < _rene_> on sid? 23:14 < _rene_> ah, on buster. yes, probably. 23:15 < _rene_> but according to the submitter and the upstream bug it does not happen on 7.0.x 23:15 < _rene_> guess I need to fire up a buster vm 23:15 < _rene_> (and probably backport the upstream fix to buster. *sigh*) 23:16 < _rene_> yeah, libreoffice-lightproof-* is python. but I have libreoffice-lightproof-en installed, too 23:16 < bunk> libreoffice-lightproof-en makes it reproducible for me on buster 23:17 < _rene_> gah. even on my testing, indeed 23:17 < _rene_> no idea what I tested before, probably I didn't do PYTHONPATH=. 23:17 < _rene_> ok, so it boils down to 23:18 < _rene_> a) buster is affected without interaction (-> bad) 23:18 < _rene_> b) testing/sid is when setting PYTHONPATH=. (-> not ideal, but one shouldn't do so(tm)) 23:21 < _rene_> thus this is something one needs to fix for buster, for testing/sid it's "user error" 23:21 * _jwilk nods. 23:22 < bunk> I see some similarities between a) and https://security-tracker.debian.org/tracker/CVE-2016-1238 23:22 < _rene_> indeed @Salvatore: Want it done via DSA? Regards, Rene
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
forwarded 984703 https://bugs.documentfoundation.org/show_bug.cgi?id=121384
thanks
Hi,
Am 07.03.21 um 22:45 schrieb Milko Krachounov:
> After some additional testing, checking my environment and inspecting pyuno/
> source/loader/pyuno_loader.cxx, I want to amend the report, particularly
> about
> 7.0.4 which is not affected (kind of).
Interestingly, in discussion on #debian-devel it is said that it does :/
See below.
> First, I wonder if someone reproduces this on 1:6.1.5-3+deb10u6 (if nobody
> does, I may whip up a VM to exclude other factors next Sunday).
Can try, too. My normal system is normally a stable but was already
upgraded to bullseye, though ("eat your own dogfood") due to the freeze.
> Indeed, however, on 1:7.0.4~rc2-1~bpo10+2 the issue is *NOT* reproducible (at
> least with the given steps, see below), and was only happening entirely due
> to
> a local misconfiguration, as I had a trailing colon inside PYTHONPATH. That
> causes Python 3 to crash with that error. My deepest apologies for polluting
> the report with the wrong information about 7.0.4.
> However, I can still reproduce this on 6.1.5, and changing absolutely nothing
> in the environment, including deletion of ~/.config/libreoffice does not seem
> to stop it, and there is no PYTHONPATH set in any form. I also noticed that
Yeah, LO does itself.
$ grep -r PYTHONPATH /usr/lib/libreoffice/*
/usr/lib/libreoffice/program/unopkg:export
PYTHONPATH="/usr/lib/libreoffice/program"
grep: /usr/lib/libreoffice/program/libpythonloaderlo.so:
Übereinstimmungen in Binärdatei
/usr/lib/libreoffice/program/pythonloader.unorc:PYUNO_LOADER_PYTHONPATH=$ORIGIN
/usr/lib/libreoffice/program/pythonloader.unorc:PYTHONPATH=$PYTHONHOME
$PYTHONHOME/site-packages $PYTHONHOME/lib-dynload $PYTHONHOME/lib-tk $ORIGIN
$
The latter is for scripts via python3-uno though.
> pyuno/source/loader/pyuno_loader.cxx from the buster source does add exactly
> such trailing colon (an issue that has been explicitly fixed in 7.0.4, so
> only
> Buster is affected):
>
> bufPYTHONPATH.append( systemPath );
> bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) );
>
> I see the code for buster-backports (and presumably bullseye) has been
> modified to not leave either trailing colons or colons surrounding an empty
> string by adding three explicit checks (except for one case, which threw off
> my testing):
>
> if (!systemPath.isEmpty())
> {
> if (bAppendSep)
>
> bufPYTHONPATH.append(static_cast(SAL_PATHSEPARATOR));
> bufPYTHONPATH.append(systemPath);
> bAppendSep = true;
> }
>
> const char * oldEnv = getenv( "PYTHONPATH");
> if( oldEnv )
> {
> if (bAppendSep)
> bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR)
> );
> bufPYTHONPATH.append( OUString(oldEnv, strlen(oldEnv),
> osl_getThreadTextEncoding()) );
> }
Yes, this looks like
https://cgit.freedesktop.org/libreoffice/core/commit/?id=327153471ae38abe90463f6272e00aaa996c5ba3
and thus https://bugs.documentfoundation.org/show_bug.cgi?id=121384
(which is filed for writer and not calc, but...)
> P.S. Yeah, LibreOffice doesn't touch encodings.py. The error is produced by
> Python during initialisation as it tries to determine the locale encoding, so
> it happens before any external Python code is executed, and only happens if
> something injects the local directory or an empty string in PYTHONPATH.
Yeah, that was told to me on #debian-devel, too:
22:14 < olly[m]1> seems potentially problematic if PYTHONPATH is
honoured here (since it could find an entirely unrelated encodings.py on
PYTHONPATH),
though not really RC or a security bug AFAICS
22:16 < _rene_> the question also is what calls encodings.py at all
22:17 < _rene_> since LO itself definitely does not
22:22 < _jwilk> Python itself loads it: https://paste.debian.net/1188328
[ content:
$ echo boom > encodings.py
$ export PYTHONPATH=/opt/moo:$PYTHONPATH # oops, if PYTHONPATH is
empty, this adds cwd
$ python3
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/jwilk/encodings.py", line 1, in
NameError: name 'boom' is not defined
Aborted ]
which would support your report. Though I still don't see it.
22:33 < _rene_> and when?
22:34 < _rene_> since PYTHONPATH=. localc test.csv still doesn't load it
22:34 < _rene_> Fatal Python error: initfsencoding: Unable to get the
locale encoding
22:34 < _rene_> only then?
22:34 < _rene_> whatever that means
22:36 < _rene_> Hmm, OK, I do get an error with LANG=en_US PYTHONPATH=.
localc test.csv
22:36 < _rene_> but nothing on the console, though
22:37 < _rene_> ah, LANG=en_US in ~/äöü is not a good idea
22:37 < _rene_> still nothing pythonish, though
22:39 < _jwilk> It does crash here: https://paste.debian.net/1188332
[ content:
$echoboom > encodings.py $echo> foo.csv
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
Hello,
After some additional testing, checking my environment and inspecting pyuno/
source/loader/pyuno_loader.cxx, I want to amend the report, particularly about
7.0.4 which is not affected (kind of).
First, I wonder if someone reproduces this on 1:6.1.5-3+deb10u6 (if nobody
does, I may whip up a VM to exclude other factors next Sunday).
Indeed, however, on 1:7.0.4~rc2-1~bpo10+2 the issue is *NOT* reproducible (at
least with the given steps, see below), and was only happening entirely due to
a local misconfiguration, as I had a trailing colon inside PYTHONPATH. That
causes Python 3 to crash with that error. My deepest apologies for polluting
the report with the wrong information about 7.0.4.
However, I can still reproduce this on 6.1.5, and changing absolutely nothing
in the environment, including deletion of ~/.config/libreoffice does not seem
to stop it, and there is no PYTHONPATH set in any form. I also noticed that
pyuno/source/loader/pyuno_loader.cxx from the buster source does add exactly
such trailing colon (an issue that has been explicitly fixed in 7.0.4, so only
Buster is affected):
bufPYTHONPATH.append( systemPath );
bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) );
I see the code for buster-backports (and presumably bullseye) has been
modified to not leave either trailing colons or colons surrounding an empty
string by adding three explicit checks (except for one case, which threw off
my testing):
if (!systemPath.isEmpty())
{
if (bAppendSep)
bufPYTHONPATH.append(static_cast(SAL_PATHSEPARATOR));
bufPYTHONPATH.append(systemPath);
bAppendSep = true;
}
const char * oldEnv = getenv( "PYTHONPATH");
if( oldEnv )
{
if (bAppendSep)
bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR)
);
bufPYTHONPATH.append( OUString(oldEnv, strlen(oldEnv),
osl_getThreadTextEncoding()) );
}
However, in spite of this fix, I was still able to reproduce a *similar*
(though significantly less impactful) issue on 7.0.4. Since the code checks if
PYTHONPATH is set (as opposed to empty), passing an empty PYTHONPATH causes
LibreOffice to crash in the same manner (while Python 3 itself does not).
With unset PYTHONPATH:
* 1:6.1.5-3+deb10u6 from Buster crashes
* 7.0.4 from Buster Backports and Bullseye DOES NOT crash
With *empty* PYTHONPATH both crash.
$ PYTHONPATH= localc ./test.csv # this triggers it on 7.0.4
$ localc ./test.csv # this triggers it on 6.1.5
Best wishes, and I again apologize for the missing report, and for reporting
an issue that is fixed (-ish) in bullseye and sid.
P.S. Yeah, LibreOffice doesn't touch encodings.py. The error is produced by
Python during initialisation as it tries to determine the locale encoding, so
it happens before any external Python code is executed, and only happens if
something injects the local directory or an empty string in PYTHONPATH.
On неделя, 7 март 2021 г. 22:14:02 EET Rene Engelhard wrote:
> tag 984703 + moreinfo
>
> tag 984703 + unreproducible
>
> thanks
>
>
> Hi,
>
> Am 07.03.21 um 13:34 schrieb Milko Krachounov:
> > When opening any CSV file with LibreOffice Calc, Calc opens and executes
> > encodings.py from the current working directory.
>
> Demonstrably wrong, see below.
>
> > That presumably happens because
> >
> > Some file managers, including Krusader and mc, would launch localc in the
> > current directory, as would running it from the command line (such as
> > `localc file.csv'), thereby running encodings.py from the directory
> > containing the file.
> >
> > The issue is not present when LibreOffice is launched through the
> > application launcher, and the file is opened later through whatever
> > means (neither Open file, nor through a file manager or the command
> > line, since localc already operates in one's $HOME in that instance)
> > To reproduce the issue, one needs to:
> > 1. Close LibreOffice *completely*
> > 2. In an empty directory, create "encodings.py" which raises an exception
>
> Created a encodings.py which contains "foo", which surely is not valid
> python.
>
> > 3. In the same directory (for simplicity), create "file.csv" with some
> >
> >rows.
>
> Did.
>
> 1,2
>
> ö,ä
>
>
> (last line to be sure there is some encoding in there)
>
> > 4. Open "file.csv" with `localc ./file.csv' using the directory containing
> >
> >"encodings.py" (double clicking in krusader and mc leads to the same
> >result)
>
> Done that.
>
> > The result is that LibreOffice crashes with the Python exception raised
> > by the rogue encodings.py, and then exits with an error that reads:
> > Fatal Python error: initfsencoding: Unable to get the locale encoding
>
> Just works here. Opens the .csv as is.
>
> > The problem is present in both Debian Stable (1:6.1.5-3+deb10u6), and
> > Buster Backports (1:7.0.4~rc2-1~bpo10+2).
>
> Tried with 7.0.4-3 on bullseye (which
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
tag 984703 + moreinfo
tag 984703 + unreproducible
thanks
Hi,
Am 07.03.21 um 13:34 schrieb Milko Krachounov:
> When opening any CSV file with LibreOffice Calc, Calc opens and executes
> encodings.py from the current working directory.
Demonstrably wrong, see below.
> That presumably happens because
>
> Some file managers, including Krusader and mc, would launch localc in the
> current directory, as would running it from the command line (such as
> `localc file.csv'), thereby running encodings.py from the directory
> containing the file.
>
> The issue is not present when LibreOffice is launched through the
> application launcher, and the file is opened later through whatever
> means (neither Open file, nor through a file manager or the command
> line, since localc already operates in one's $HOME in that instance)
> To reproduce the issue, one needs to:
> 1. Close LibreOffice *completely*
> 2. In an empty directory, create "encodings.py" which raises an exception
Created a encodings.py which contains "foo", which surely is not valid
python.
> 3. In the same directory (for simplicity), create "file.csv" with some
>rows.
Did.
1,2
ö,ä
(last line to be sure there is some encoding in there)
> 4. Open "file.csv" with `localc ./file.csv' using the directory containing
>"encodings.py" (double clicking in krusader and mc leads to the same
>result)
Done that.
> The result is that LibreOffice crashes with the Python exception raised
> by the rogue encodings.py, and then exits with an error that reads:
> Fatal Python error: initfsencoding: Unable to get the locale encoding
Just works here. Opens the .csv as is.
> The problem is present in both Debian Stable (1:6.1.5-3+deb10u6), and
> Buster Backports (1:7.0.4~rc2-1~bpo10+2).
Tried with 7.0.4-3 on bullseye (which should be identical to the
backport you use in this regard)
> No extensions not installed
> by apt are present on either machine (on the one with 6.1.5 I never
> installed any, and on the 7.0.4 I'm trusting what the LO extension
> manager is telling me, since I cannot recall for sure)
Something else you did?
> Here's the console chatter:
>
> # Test on the host with 1:7.0.4~rc2-1~bpo10+2 - hostname is censored
> milko@host2 ~/Временна/LOSecurity $ cat > encodings.py
Maybe it is because of the *dir* this is in? I am so sure not creating a
cyrillic directory to check.
But even in a ~/öäü I just created, no crash and just an open of the .csv
> raise NotImplementedError("Darth Vader, Obi-Wan and Ahsoka walk into a bar")
> milko@host2 ~/Временна/LOSecurity $ cat > test.csv
> Column 1;Column 2;Column 3
> текст;ຂໍ້ຄວາມ;text
> milko@host2 ~/Временна/LOSecurity $ localc test.csv
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
> File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
> File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> milko@host2 ~/Временна/LOSecurity $ cat > test2.csv
> Column 1;Column 2;Column 3
> text1;text2;text3
> milko@host2 ~/Временна/LOSecurity $ localc test2.csv
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
> File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> Application Error
> milko@host2 ~/Временна/LOSecurity $
Even this doesn't produce any error. (in my ~/aöü)
>> Can yu pleas make this directly a public report in the Debian BTS?
Are you serious? For something unreproducible? Or were you able to
reproduce it?
Regards,
Rene
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
Hi again, Am 07.03.21 um 13:34 schrieb Milko Krachounov: > When opening any CSV file with LibreOffice Calc, Calc opens and executes > encodings.py from the current working directory. That presumably happens > because There also is no mention of any "encodings.py" in anything in LibreOffice itself: rene@frodo:~/LibreOffice/git/libreoffice-7-0-4$ git grep encodings config_host/config_locales.h.in: * support all the locales and character encodings that it has code configure.ac: tables for encodings mainly targeted for a cui/source/tabpages/tpline.cxx:// Convert URL encodings to UI characters (e.g. %20 for spaces) [ internal python3 (which we don't use) encoding stuff stripped ] filter/qa/complex/filter/detection/typeDetection/TypeDetection.java: * is used as source for several encodings. filter/source/graphicfilter/idxf/dxfreprd.cxx:// Its Windows variant, and later releases used ANSI encodings for filter/source/graphicfilter/idxf/dxfreprd.cxx:// encodings for storing to corresponding formats, but there's filter/source/graphicfilter/idxf/dxfreprd.cxx:// $DWGCODEPAGE to encodings mappings filter/source/msfilter/util.cxx:// in last-ditch broken-file-format cases to guess the right 8bit encodings framework/qa/complex/loadAllDocuments/CheckXComponentLoader.java: * is used as source for several encodings. include/filter/msfilter/util.hxx:/// i.e. useful when dealing with legacy formats which use legacy text encodings without recording include/rtl/string.h:for double-byte encodings, UTF-7, UTF-8). include/rtl/tencinfo.h:Can be rather meaningless for encodings that encode global state along include/rtl/tencinfo.h:with the characters (e.g., ISO-2022 encodings). include/rtl/tencinfo.h:Can be rather meaningless for encodings that encode global state along include/rtl/tencinfo.h:with the characters (e.g., ISO-2022 encodings). include/rtl/tencinfo.h:characters (SS2 and SS3) used by some of the EUC encodings (to denote include/rtl/tencinfo.h:repertoire) do not imply that encodings making use of these characters include/rtl/tencinfo.h:have the CONTEXT property. Examples of encodings that do have the include/rtl/tencinfo.h:CONTEXT property are the ISO-2022 encodings and UTF-7. include/rtl/tencinfo.h:special purposes in some encodings. include/rtl/textenc.h:/** The various supported text encodings. include/rtl/textenc.h:Possible values include a wide range of single- and multi-byte encodings include/rtl/textenc.h:the ISO 10646 (Unicode) specific encodings RTL_TEXTENCODING_UCS4 and include/rtl/textenc.h:These encodings are not used for text encodings, only used for include/rtl/textenc.h:font-/textoutput encodings. include/rtl/uri.h:converted to eCharset because it contains (encodings of) unmappable include/rtl/ustring.h:for double-byte encodings, UTF-7, UTF-8). include/rtl/ustring.hxx:encodings, UTF-7, UTF-8). include/rtl/ustring.hxx:encodings, UTF-7, UTF-8). include/svx/txencbox.hxx:/** Fill with all known encodings but exclude those matching one or more include/svx/txencbox.hxx: If nButIncludeInfoFlags is given, encodings are included even if they include/svx/txencbox.hxx:If , some specific encodings are not listed, as they are a include/svx/txencbox.hxx:/** Fill with all encodings known to the dbtools::OCharsetMap but exclude include/svx/txencbox.hxx: If nButIncludeInfoFlags is given, encodings are included even if they include/svx/txencbox.hxx:If , some specific encodings are not listed, as they are a include/svx/txencbox.hxx:/** Fill with all known MIME encodings and select the best according to include/svx/txencbox.hxx:/** Fill with all known encodings but exclude those matching one or more include/svx/txencbox.hxx:If , some specific encodings are not listed, as they are a include/svx/txencbox.hxx:/** Fill with all encodings known to the dbtools::OCharsetMap but exclude include/svx/txencbox.hxx:If , some specific encodings are not listed, as they are a include/tools/tenccvt.hxx:/// encoding. The encodings could be different. sal/osl/unx/nlsupport.cxx: * _nl_language_list[] is an array list of supported encodings. Because sal/osl/unx/nlsupport.cxx: * We are comparing the encodings case insensitive, so the list has sal/qa/rtl/uri/rtl_testuri.cxx:// Check encode with unusual text encodings: sal/rtl/ustring.cxx: code here. Could be the case for apple encodings */ sal/textenc/tcvtbyte.hxx:/** For those encodings only with unicode range of 0x80 to 0xFF. */ sal/textenc/tcvtmb.cxx:/* then share many tables for different charset encodings. */ sal/textenc/tcvtmb.cxx:/* so that extensions that don't consider encodings */ sal/textenc/tcvtmb.cxx:/* so that extensions that don't consider
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
Package: libreoffice-calc
Version: 1:6.1.5-3+deb10u6
Severity: grave
Tags: security
Justification: user security hole
Dear Maintainer,
When opening any CSV file with LibreOffice Calc, Calc opens and executes
encodings.py from the current working directory. That presumably happens
because
Some file managers, including Krusader and mc, would launch localc in the
current directory, as would running it from the command line (such as
`localc file.csv'), thereby running encodings.py from the directory
containing the file.
The issue is not present when LibreOffice is launched through the
application launcher, and the file is opened later through whatever
means (neither Open file, nor through a file manager or the command
line, since localc already operates in one's $HOME in that instance)
To reproduce the issue, one needs to:
1. Close LibreOffice *completely*
2. In an empty directory, create "encodings.py" which raises an exception
3. In the same directory (for simplicity), create "file.csv" with some
rows.
4. Open "file.csv" with `localc ./file.csv' using the directory containing
"encodings.py" (double clicking in krusader and mc leads to the same
result)
The result is that LibreOffice crashes with the Python exception raised
by the rogue encodings.py, and then exits with an error that reads:
Fatal Python error: initfsencoding: Unable to get the locale encoding
An offer is made to recover the unsaved file (but the list is empty),
relaunching LO sometimes leads to new crashes.
This is NOT the only way the issue happens, I was able to get the
same crash while clicking through the menus or editing an .ods
which initially didn't cause a crash, but those aren't deterministically
reproduced, whereas the .csv route seems to guarantee a crash for me
even when the .csv is ASCII.
The problem is present in both Debian Stable (1:6.1.5-3+deb10u6), and
Buster Backports (1:7.0.4~rc2-1~bpo10+2). No extensions not installed
by apt are present on either machine (on the one with 6.1.5 I never
installed any, and on the 7.0.4 I'm trusting what the LO extension
manager is telling me, since I cannot recall for sure)
Here's the console chatter:
# Test on the host with 1:7.0.4~rc2-1~bpo10+2 - hostname is censored
milko@host2 ~/Временна/LOSecurity $ cat > encodings.py
raise NotImplementedError("Darth Vader, Obi-Wan and Ahsoka walk into a bar")
milko@host2 ~/Временна/LOSecurity $ cat > test.csv
Column 1;Column 2;Column 3
текст;ຂໍ້ຄວາມ;text
milko@host2 ~/Временна/LOSecurity $ localc test.csv
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
milko@host2 ~/Временна/LOSecurity $ cat > test2.csv
Column 1;Column 2;Column 3
text1;text2;text3
milko@host2 ~/Временна/LOSecurity $ localc test2.csv
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
Application Error
milko@host2 ~/Временна/LOSecurity $
# Test on the host with 1:6.1.5-3+deb10u6 - hostname is censored
# The encodings.py and test.csv were copied from host2
milko@host1 ~/Временни/LOSecurity $ localc test2.csv
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/milko/Временни/LOSecurity/encodings.py", line 1, in
NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
milko@host1 ~/Временни/LOSecurity $ lowriter
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/milko/Временни/LOSecurity/encodings.py", line 1, in
NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
^C
milko@host1 ~/Временни/LOSecurity $
LO packages installed on host1 and host2. I do apologize for the untidy
mess with transitional and unpurged packages and leftover from the dawn of
time (especially on host2) -- I didn't expect someone to be looking through
my messy house -- but I have to leave them here in case one of them comes
responsible.
milko@host2 ~ $ dpkg -l | grep -i -e libreoffice -e 1:7.0.4~rc2-1~bpo10+2
ii hyphen-ru 20030310-1
all Russian hyphenation patterns for
LibreOffice/OpenOffice.org
ii jabref-plugin-oo2.10+ds-3
all LibreOffice plugin for JabRef
(transitional dummy package)
ii libjuh-java
