[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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_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()) );
    }

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 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 <module>
> > 
> > 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 <module>
> > 
> > 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 <module>
> > 
> > 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
Reply to: