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 e
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
bus-glib-1-2 0.110-4 ii libdconf1 0.30.1-2 ii libeot0 0.01-5 ii libepoxy0 1.5.3-0.1 ii libexpat1 2.2.6-2+deb10u1 ii libexttextcat-2.0-0 3.4.5-1 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3+deb10u2 ii libgcc1 1:8.3.0-6 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgpgmepp6 1.12.0-6 ii libgraphite2-31.3.13-7 ii libharfbuzz-icu0 2.3.1-1 ii libharfbuzz0b 2.3.1-1 ii libhunspell-1.7-0 1.7.0-2 ii libhyphen02.8.8-7 ii libice6 2:1.0.9-2 ii libicu63 63.1-6+deb10u1 ii libjpeg62-turbo 1:1.5.2-2+deb10u1 ii liblcms2-22.9-3 ii libldap-2.4-2 2.4.47+dfsg-3+deb10u6 ii libmythes-1.2-0 2:1.2.4-3 ii libneon27-gnutls 0.30.2-3 ii libnspr4 2:4.20-1 ii libnss3 2:3.42.1-1+deb10u3 ii libnumbertext-1.0-0 1.0.5-1 ii libodfgen-0.1-1 0.1.7-1 ii liborcus-0.14-0 0.14.1-6 ii libpng16-16 1.6.36-6 ii libpoppler82 0.71.0-5 ii librdf0 1.0.17-1.1+b1 ii libreoffice-common1:6.1.5-3+deb10u6 ii librevenge-0.0-0 0.0.4-6 ii libsm62:1.2.3-1 ii libstdc++68.3.0-6 ii libx11-6 2:1.6.7-1+deb10u1 ii libxext6 2:1.3.3-1+b2 ii libxinerama1 2:1.1.4-2 ii libxml2 2.9.4+dfsg1-7+deb10u1 ii libxmlsec11.2.27-2 ii libxmlsec1-nss1.2.27-2 ii libxrandr22:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.11.1.32-2.2~deb10u1 ii uno-libs3 6.1.5-3+deb10u6 ii ure 6.1.5-3+deb10u6 ii zlib1g1:1.2.11.dfsg-1 Versions of packages libreoffice-core recommends: ii libpaper-utils 1.1.28 -- no debconf information On Sunday, 7 March 2021, 14:18:33 EET Salvatore Bonaccorso wrote: > Hi Milko, > > On Sat, Feb 27, 2021 at 08:36:31PM +0200, Milko Krachounov wrote: > > 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
Bug#909999: ghostscript (via pdf2ps) crashes on most inputs following upgrade to 9.06~dfsg-2+deb8u9
I can confirm this issue. Downgrading back to ghostscript_9.06~dfsg-2+deb8u8_amd64.deb ghostscript-x_9.06~dfsg-2+deb8u8_amd64.deb libgs9_9.06~dfsg-2+deb8u8_amd64.deb libgs9-common_9.06~dfsg-2+deb8u8_all.deb fixes the issue for me. Trying to convert a XeLaTeX-produced document leads to this error: $ pdf2ps article.pdf Error: /rangecheck in .installpagedevice Operand stack: --nostringval-- --dict:174/176(ro)(L)-- --nostringval-- --nostringval-- false Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop --nostringval-- 1839 1 4 %oparray_pop --nostringval-- 1823 1 4 %oparray_pop --nostringval-- --nostringval-- Dictionary stack: --dict:939/1684(ro)(G)-- --dict:1/20(G)-- --dict:77/200(L)-- --dict:77/200(L)-- Current allocation mode is local GPL Ghostscript 9.06: Unrecoverable error, exit code 1
Bug#760191: Fixed
On 23 September 2014 09:15:32 Soren Stoutner wrote: An update to the latest packages from testing appears to have fixed this problem for me. I have not yet exhaustively checked for remaining errors, but I an now receiving new emails. Yes. The bug appears to be fixed now. After an upgrade the problem is gone for me as well, on both machines and with all three mail servers where I was experiencing the problem. I include the full list of packages that have been upgraded in the batch that fixed it. I realise it's a bit too extensive, but I'm not sure which packages might have caused the problem, so I include everything for reference. Also some packages aren't from the official Debian archives (they come from Deb Multimedia), but they are all unrelated to Akonadi and KMail. I hope they are not an issue. :) 2014-09-23 03:13:21 status installed dbus:amd64 1.8.6-2 2014-09-23 03:13:22 status installed man-db:amd64 2.6.7.1-1 2014-09-23 03:13:41 status installed hicolor-icon-theme:all 0.13-1 2014-09-23 03:13:42 status installed libmbim-glib0:amd64 1.8.0-1 2014-09-23 03:13:44 status installed libc-bin:amd64 2.19-11 2014-09-23 03:14:02 status installed man-db:amd64 2.6.7.1-1 2014-09-23 03:14:05 status installed menu:amd64 2.1.47 2014-09-23 03:14:09 status installed mime-support:all 3.56 2014-09-23 03:14:10 status installed desktop-file-utils:amd64 0.22-1 2014-09-23 03:14:12 status installed hicolor-icon-theme:all 0.13-1 2014-09-23 03:14:13 status installed libprotobuf8:amd64 2.5.0-9 2014-09-23 03:14:14 status installed libc-bin:amd64 2.19-11 2014-09-23 03:14:35 status installed man-db:amd64 2.6.7.1-1 2014-09-23 03:14:36 status installed menu:amd64 2.1.47 2014-09-23 03:14:37 status installed mime-support:all 3.56 2014-09-23 03:14:37 status installed desktop-file-utils:amd64 0.22-1 2014-09-23 03:14:40 status installed hicolor-icon-theme:all 0.13-1 2014-09-23 03:14:41 status installed libvlccore7:amd64 1:2.1.5-dmo2 2014-09-23 03:14:42 status installed libc-bin:amd64 2.19-11 2014-09-23 03:18:23 status installed man-db:amd64 2.6.7.1-1 2014-09-23 03:19:14 status installed shared-mime-info:amd64 1.3-1 2014-09-23 03:19:15 status installed libglib2.0-0:i386 2.40.0-5 2014-09-23 03:19:16 status installed libglib2.0-0:amd64 2.40.0-5 2014-09-23 03:19:19 status installed hicolor-icon-theme:all 0.13-1 2014-09-23 03:19:20 status installed mime-support:all 3.56 2014-09-23 03:19:21 status installed desktop-file-utils:amd64 0.22-1 2014-09-23 03:19:34 status installed cups:amd64 1.7.5-1 2014-09-23 03:19:35 status installed menu:amd64 2.1.47 2014-09-23 03:19:35 status installed dbus:amd64 1.8.6-2 2014-09-23 03:19:37 status installed doc-base:all 0.10.6 2014-09-23 03:19:45 status installed python-support:all 1.0.15 2014-09-23 03:19:47 status installed libmbim-glib4:amd64 1.10.0-2 2014-09-23 03:19:47 status installed libmbim-proxy:amd64 1.10.0-2 2014-09-23 03:19:48 status installed libmm-glib0:amd64 1.4.0-1 2014-09-23 03:19:48 status installed libqmi-glib1:amd64 1.10.2-2 2014-09-23 03:19:48 status installed libqmi-proxy:amd64 1.10.2-2 2014-09-23 03:19:50 status installed libprotobuf9:amd64 2.6.0-3 2014-09-23 03:19:51 status installed mosh:amd64 1.2.4a-1+b2 2014-09-23 03:19:51 status installed libphonenumber6:amd64 6.3~svn698-3+b1 2014-09-23 03:19:51 status installed libavutil54:amd64 10:2.4-dmo1 2014-09-23 03:19:52 status installed libavutil54:i386 10:2.4-dmo1 2014-09-23 03:19:52 status installed libmp3lame0:amd64 1:3.99.5-dmo3 2014-09-23 03:19:53 status installed libmp3lame0:i386 1:3.99.5-dmo3 2014-09-23 03:19:53 status installed libswresample1:i386 10:2.4-dmo1 2014-09-23 03:19:53 status installed libswresample1:amd64 10:2.4-dmo1 2014-09-23 03:19:54 status installed libx265-31:i386 1.3-dmo1 2014-09-23 03:19:54 status installed libzvbi0:i386 0.2.33-7 2014-09-23 03:19:55 status installed libavcodec56:i386 10:2.4-dmo1 2014-09-23 03:19:56 status installed libavcodec56:amd64 10:2.4-dmo1 2014-09-23 03:19:56 status installed libchromaprint0:amd64 1.2-dmo2 2014-09-23 03:19:56 status installed clementine:amd64 1.2.3+dfsg-2+b1 2014-09-23 03:19:57 status installed libavformat56:amd64 10:2.4-dmo1 2014-09-23 03:19:57 status installed liblircclient0:amd64 0.9.0~pre1-1.1 2014-09-23 03:19:58 status installed libpostproc53:amd64 10:2.4-dmo1 2014-09-23 03:19:59 status installed libswscale3:amd64 10:2.4-dmo1 2014-09-23 03:19:59 status installed libvcdinfo0:amd64 0.7.24+dfsg-0.2 2014-09-23 03:20:00 status installed vlc-data:all 1:2.2.0~pre3-dmo2 2014-09-23 03:20:00 status installed libvlccore8:amd64 1:2.2.0~pre3-dmo2 2014-09-23 03:20:01 status installed libvlc5:amd64 1:2.2.0~pre3-dmo2 2014-09-23 03:20:01 status installed vlc-nox:amd64 1:2.2.0~pre3-dmo2 2014-09-23 03:20:01 status installed vlc:amd64 1:2.2.0~pre3-dmo2 2014-09-23 03:20:02 status installed vlc-plugin-notify:amd64 1:2.2.0~pre3-dmo2 2014-09-23 03:20:02 status installed vlc-plugin-pulse:all 1:2.2.0~pre3-dmo2 2014-09-23 03:20:02 status installed phonon-backend-vlc:amd64 1:0.8.0-dmo2
Bug#760191: After upgrade 1.13.0-1 of akonadi-server, no new mail in IMAP folders is ever read
On 2014-09-10 12:17, Franz Schrober wrote: You provide nearly no information about your accounts or what you are doing. So please add more information. Is this the same problem as reported by me here or are you using a different setup: https://bugs.kde.org/show_bug.cgi?id=338967 The two servers that the problem occurs with are Courier IMAP on Debian Wheezy. I just noticed it doesn't occur with Gmail. After disabling TLS, here's the TCP traffic (with IP addresses removed) that I get when I try to refresh the folder: XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A34 EXPUNGE YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: A34 OK EXPUNGE completed XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A35 SELECT INBOX YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: * FLAGS ($MDNSent NonJunk $REPLIED $FORWARDED \Draft \Answered \Flagged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS ($MDNSent NonJunk $REPLIED $FORWARDED \* \Draft \Answered \Flagged \Deleted \Seen)] Limited * 4260 EXISTS * 0 RECENT * OK [UIDVALIDITY 1056698153] Ok * OK [MYRIGHTS acdilrsw] ACL A35 OK [READ-WRITE] Ok XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A36 UID SEARCH UID 1:-1 YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: A36 NO Error in IMAP command received by server. XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A37 GETACL INBOX YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: * ACL INBOX owner acdilrsw administrators acdilrsw A37 OK GETACL completed. XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A38 MYRIGHTS INBOX YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: * MYRIGHTS INBOX acdilrsw A38 OK MYRIGHTS completed. XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A39 GETQUOTAROOT INBOX YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: * QUOTAROOT INBOX ROOT * QUOTA ROOT A39 OK GETQUOTAROOT Ok. The features supported by the server are the following: IMAP4REV1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760191: akonadi-server: After upgrade 1.13.0-1 of akonadi-server, no new mail in IMAP folders is ever read
Package: akonadi-server Version: 1.13.0-1 Severity: grave Justification: renders package unusable Dear Maintainer, After upgrading two jessie machines to newest akonadi (1.13.0) and KDE, as well as libqt4-sql-mysql (4.8.6+git49-gbc62005+dfsg-1), any mails received since the upgrade (2014-08-29 and this morning, respectively) are not seen by kmail. There are no relevant errors in the akonadi error log (note to self: stop trying to use it, it is never going to get better), I cannot give any more details. I suspect the bug is triggered by libqt4-sql-mysql, because checking my last email timestamps would seem to correspond with it (it was pushed later than the other packages), but I have no way to tell for sure. I have the following in a past akonadi server log, but it isn't present in any current one: Control process died, committing suicide! Also, akonadi control log contains the following on both machines, but it seems unrelated: Executable akonadi_nepomuk_feeder for agent akonadi_nepomuk_feeder could not be found! Executable akonadi_folderarchive_agent for agent akonadi_folderarchive_agent could not be found! I manually ran mysql_upgrade on one of the machines, because MySQL was complaining about outdated tables. The other has not displayed any difference in logs. My mysql is version 5.5.37-1 (missing from the report below for some reason). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (700, 'testing'), (601, 'stable-updates'), (600, 'stable'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.1 (SMP w/4 CPU cores) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages akonadi-server depends on: ii akonadi-backend-mysql 1.13.0-1 ii libakonadiprotocolinternals11.13.0-1 ii libboost-program-options1.55.0 1.55.0+dfsg-2 ii libc6 2.19-9 ii libgcc1 1:4.9.1-4 ii libqt4-dbus 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libqt4-sql 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libqt4-xml 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libstdc++6 4.9.1-4 akonadi-server recommends no packages. Versions of packages akonadi-server suggests: ii akonadi-backend-mysql 1.13.0-1 pn akonadi-backend-postgresql none pn akonadi-backend-sqlite none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519556: xserver-xorg-input-tslib: Segfault with no RandR support
I've just tried xserver-xorg-input-tslib_0.0.5-8_armel. I'm using it on Neo 1973 (gta01) with fbdev as a video device driver. 1. Without Rotate option, it works perfectly fine, as do 2. With `Option Rotate CCW' it doesn't crash, but the clicks are not handled correctly, as they go to a different point of the screen. Sliding my finger horizontally results in a vertical cursor motion, and vica versa, so it seems that tslib doesn't know that the screen is rotated. The result with 0.0.5-7 is the same for me. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
