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_Unicode>(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_Unicode>(SAL_PATHSEPARATOR));
> bufPYTHONPATH.append(systemPath);
> bAppendSep = true;
> }
> ....
> const char * oldEnv = getenv( "PYTHONPATH");
> if( oldEnv )
> {
> if (bAppendSep)
> bufPYTHONPATH.append( static_cast<sal_Unicode>(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 <module>
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 $PYTHONPATH=. localc foo.csv
javaldx: Could not find a Java Runtime Environment!Please ensure that a
JVM and the package libreoffice-java-commonis installed.If it is already
installed then try removing
~/.config/libreoffice/4/user/config/javasettings_Linux_*.xmlWarning:
failed to read path from javaldxPython path configuration:PYTHONHOME =
(not set)PYTHONPATH = '/usr/lib/libreoffice/program:.'program name =
'python3'isolated = 0environment = 1user site = 1import site =
1sys._base_executable = '/usr/bin/python3'sys.base_prefix =
'/usr'sys.base_exec_prefix = '/usr'sys.platlibdir = 'lib'sys.executable
= '/usr/bin/python3'sys.prefix = '/usr'sys.exec_prefix = '/usr'sys.path
=
['/usr/lib/libreoffice/program','.','/usr/lib/python39.zip','/usr/lib/python3.9','/usr/lib/python3.9/lib-dynload',]Fatal
Python error: init_fs_encoding: failed to get the Python codec of the
filesystem encodingPython runtime state: core initializedTraceback (most
recent call last):File "./encodings.py", line 1, in <module>NameError:
name 'boom' is not defined ]
22:40 < _rene_> hrm.
22:40 < _rene_> not here.
22:41 < _rene_> do you have some debug python output there? I don't see
anything on the console.
22:41 < _rene_> in any case, if python runs it it imho is a python bug,
isn't it?
22:45 -!- jochensp [~jochensp@00020ef4.user.oftc.net] has quit [Quit:
WeeChat 3.0.1]
22:45 -!- jochensp [~jochensp@00020ef4.user.oftc.net] has joined
#debian-devel
22:52 < _rene_> _jwilk: did you try on stable or on testing/sid?
22:52 < _rene_> _jwilk: submitter updates the bug that it indeed doesn't
happen in 7.0.4...
22:53 < _jwilk> unstable
22:53 < _rene_> hrm.
22:56 < _rene_> may I cc you on my reply to the bug? :)
22:56 < _jwilk> Sure.
22:57 < _jwilk> Assuming that there's really cwd in PYTHONPATH, that's a
user error, not a Python bug.
22:57 < _jwilk> (Except that Python makes it too easy to add empty entry
to PYTHONPATH by accident.)
22:58 < _rene_> https://bugs.documentfoundation.org/show_bug.cgi?id=121384
22:58 < _rene_> which resulted in
https://cgit.freedesktop.org/libreoffice/core/commit/?id=327153471ae38abe90463f6272e00aaa996c5ba3
22:58 < _rene_> which would match the submitters claim that 7.0.x is not
affected
CC'ing Jakub with his permission.
Regards,
Rene
Reply to: