Description: I have an ODT document created from a web page years ago by using copy & paste. When I open the ODT document now with LibreOffice 6.1.3.2 as of Debian Buster (testing) 6.1.3-1, I get two error dialog popups "Error: General Error. General input/output error." which lack any useful information. In the LibreOficce document history I can see that LO tried to open a document named "http:tweet_button.<hexadecimal code>.html". I need to add that this behaviour is quite new, older versions of LibreOffice apparently ignored the embedded code (which I can determine from the time to load and display the document and, there was no error message). I can only conclude that LibreOffice has tried to execute certain parts of invisibly embedded JavaScript code or comparable code mechanisms. Which is categorically undesirable. Copy & Paste should not embed active code. ODT should not execute embedded website code which is unsuitable in office documents. Steps to Reproduce: 1. Load document. 2. 3. Actual Results: Waiting time. Two error pop-up dialogs. File history: Attempted tweet button document load. Expected Results: Active elements (code) should be ignored in ODT loading. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info:
Created attachment 147021 [details] The ODT document concerned.
This bug might have a security impact. Please consider classifying it as such.
Created attachment 147023 [details] document without embedded code When you copy something from the web always paste the content in paste special as "Paste Unformatted Text". You can delete the old document, look at the attachment And yes there should be a warning if there is hiding embedded code when copy/past from some social media's. anyone else, any idee???
I confirm this with Version: 6.2.0.0.beta1 (x64) Build ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (de_DE); UI-Language: en-GB Calc: threaded and Version: 6.1.3.2 (x64) Build-ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group threaded but not with Version: 5.4.7.2 (x64) Build-ID: c838ef25c16710f8838b1faec480ebba495259d0 CPU-Threads: 4; BS: Windows 6.19; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL
Maxim: thought you might be interested in this one since it concerns paste unformatted/paste special.
Bug confirmed with following condition Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
Hi Hung-Shin,Tsai, Thanks for checking this bug. Use the field version to reflect the earliest affected version...
This seems to have begun at the below commit. Adding Cc: to Armin Le Grand ; Could you possibly take a look at this one? Thanks 64dc82300c9de4b4c8a9062b7f25bd7adde5a4ca is the first bad commit commit 64dc82300c9de4b4c8a9062b7f25bd7adde5a4ca Author: Jenkins Build User <tdf@pollux.tdf> Date: Sun Jun 17 12:42:12 2018 +0200 source 8383bdc2aed96fc7905c20cc5de4ff64641e7949 author Armin Le Grand <Armin.Le.Grand@cib.de> 2018-06-07 09:44:02 +0200 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2018-06-14 18:45:56 +0200 commit 8383bdc2aed96fc7905c20cc5de4ff64641e7949 (patch) tree 734677bee7bc707ce824f66c0554f49be52d1270 parent 4b1490406d5ff419f632b581bed9744291600dc0 (diff) Replace SVGFilter using SVGIO
Dear Yan, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I am the original reporter and I use LibreOffice 6.1.5.2 now as of my Debian Linux distribution and I can confirm that parts of active webpage code are still being processed.
Un-Ccing developer for the moment, old regression & very high workload.
the document contains these floating frames which were originally IFrames in the HTML, and just like IFrames in HTML they are automatically loaded from the URL. <draw:floating-frame xlink:href="http://platform.twitter.com/widgets/tweet_button.d73d0c4cb6af3df0ea22b7c11dbc87d2.de.html#..."> this behavior was eventually reported in a different venue and now we have: https://www.libreoffice.org/about-us/security/advisories/cve-2023-2255/ "In versions >= 7.4.7 (and >= 7.5.3) the existing "update link" manager has been expanded to additionally control the update of the content of IFrames, so such IFrames will not automatically refresh their content unless the user agrees via the prompts." so perhaps this bug is fixed now? (in any case, no embedded JavaScript code is executed) it is very unclear what this would have to do with the commit of comment #8 though as no SVG file appears to be involved.
probably that got done around commit 52aa46468531918eabfa2031dedf50377ae72cf7 Author: Caolán McNamara <caolanm@redhat.com> Date: Thu Apr 13 11:49:18 2023 +0100 query getUserAllowsLinkUpdate for the case of content in a floating frame or thereabouts. There were later commits to tighten up what could appear inside such a floating frame later IIRC.