Bug 77485 - CONFIGURATION: macro-warning: path for trusted locations from previous LibreOffice, is corrupted by update
Summary: CONFIGURATION: macro-warning: path for trusted locations from previous LibreO...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.3.0.0.alpha0+ Master
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: mab4.3
  Show dependency treegraph
 
Reported: 2014-04-15 13:05 UTC by Alex Kempshall
Modified: 2014-08-13 12:40 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Kempshall 2014-04-15 13:05:37 UTC
Starting point a working system in LO 4.2.3 where the directory 
"/home/master/Documents/openoffice" 
is a trusted location. An odb document with macros opens successfully.

When running with the same .config as in LO 4.2.3 and opening a document containing macros using LO 4.3.0.alpha0+Master the "This document contains macros" dialog appears.

When drilling down through 

Tools -> options -> Security -> Macro Security -> Trusted Sources -> Trusted File Locations

I find that LO 4.3.0.alpha+Master has corrupted the name of the Trusted Location from 

"/home/master/Documents/openoffice" as in LO 4.2.3

to 

"/home/master/Documents/Documents/openoffice" as in LO 4.3.0.alpha+Master

i.e. the last directory name has been repeated twice

Alex
Comment 1 Robert Großkopf 2014-04-15 15:29:26 UTC
Could confirm this buggy behavior. It's the same in LO 4.3.0.0beta. The path is changed from
/home/<user>/Documents
to
/home/<user>/Documents/Documents
and don't find the path. 
If you correct this in LO 4.3.0.0beta to
/home/<user>/Documents
and start LO 4.1.* again there you could read
/home/<user>
This would be a security-problem. I will set the Importance to high an major.

It isn't a special database-problem but a problem of the whole LO. Don't know if it is right to set the Component to UI ...
Comment 2 Cor Nouws 2014-07-07 08:09:12 UTC
Hi - some better summary & component!
Comment 3 Alex Kempshall 2014-07-07 09:15:34 UTC
Are you asking for more detail?
Comment 4 Adolfo Jayme Barrientos 2014-07-07 18:49:00 UTC
@Alex: Cor left that comment while changing this bug’s component and summary, as you can tell from the e-mail message Bugzilla sent you/from the “History” page. :-)
Comment 5 Stephan Bergmann 2014-08-12 15:23:33 UTC
I cannot reproduce this (Linux x86_64).  After "rm -rf ~/.config/libreoffice", starting a LO 4.2 and add to "Tools - Options... - LibreOffice - Security - Macro Security... - Trusted Sources - Trusted file locations" the existing directory /home/me/Documents/safe.  ~/.config/libreoffice/4/user/registrymodifications.xcu now contains

  <item oor:path="/org.openoffice.Office.Common/Security/Scripting"><prop oor:name="SecureURL" oor:op="fuse"><value><it>$(work)/safe</it></value></prop></item>

The start a LO 4.3 and "Tools - Options... - LibreOffice - Security - Macro Security... - Trusted Sources - Trusted file locations" still lists /home/me/Documents/safe (and ~/.config/libreoffice/4/user/registrymodifications.xcu still contains the unchanged /org.openoffice.Office.Common/Security/Scripting/SecureURL prop).
Comment 6 Alex Kempshall 2014-08-12 17:09:00 UTC
I'll shall see if I can re-create it.

The bug was confirmed - see Comment #1.
Comment 7 Robert Großkopf 2014-08-12 18:47:45 UTC
I had reproduced this in comment1, but couldn't reproduce the bug any more with LO 4.3.0.4. Don't know how it has been gone.
Comment 8 Alex Kempshall 2014-08-12 19:41:53 UTC
I can't reproduce the bug on 

Fresh - 4.3.0.4

or on 

4.4.0.0.alpha0+


So this bug can be closed. Who should do that?
Comment 9 Robert Großkopf 2014-08-13 12:40:43 UTC
I will close the bug as "Resolved" "Worksforme". Don't know what has solved the problem.