Bug 111696 - No macro security dialog with High setting
Summary: No macro security dialog with High setting
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:6.0.0
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks: Dialog Macro
  Show dependency treegraph
 
Reported: 2017-08-11 14:45 UTC by Aron Budea
Modified: 2017-08-30 17:48 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
bt with debug symbols (5.11 KB, text/plain)
2017-08-12 07:07 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2017-08-11 14:45:31 UTC
- Make sure Macro security setting is set to High.
- Open a file with macro, eg. attachment 132647 [details], an XLSM file.

=> The usual popup that "This document contains macros." etc. doesn't show.
Security settings are still enforced.
With Medium settings the popup is there.

Encountered in 6.0 daily build (4e2b44860c2c304ea728c512b47ca07aaf1cd452, 2017-08-10_23:01:09) / Ubuntu 17.04 & Windows 7.
Popup is there in 5.4.0.3.
=> regression
Comment 1 Xisco Faulí 2017-08-11 14:49:37 UTC
Confirmed in

Versió: 6.0.0.0.alpha0+
ID de la construcció: 0342c5e8086c8200ecadbe9d52dd4ef6a093effb
CPU threads: 4; OS: Linux 4.10; UI render: per defecte; VCL: gtk3; 
Configuració local: ca-ES (ca_ES.UTF-8); Calc: group
Comment 2 Xisco Faulí 2017-08-11 14:59:53 UTC
Regression introduced by:

author	Noel Grandin <noel.grandin@collabora.co.uk>	2017-02-09 06:52:13 (GMT)
committer	Noel Grandin <noel.grandin@collabora.co.uk>	2017-06-21 06:42:30 (GMT)
commit	528632660b72b105345945c13c5b68060d94a91b (patch)
tree	860508d482959abeb9175f0ce6b9e65954269f95
parent	aee66aa85e75f67135e5c6079a281e18402d261a (diff)
convert ErrCode to strong typedef
would have preferred to re-use o3tl::strong_int, of which this
is a modified copy, but there are lots of convenience accessors
which are nice to define on the class.

bisected with bibisect-linux64-6.0

Adding Cc: to Noel Grandin
Comment 3 Aron Budea 2017-08-11 20:40:55 UTC Comment hidden (obsolete)
Comment 4 Aron Budea 2017-08-11 21:47:36 UTC
Scratch that, that piece of code must've behaved the same before as well.
Comment 5 Julien Nabet 2017-08-12 07:07:38 UTC
Created attachment 135479 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated yesterday, noticing this trace:
warn:legacy.osl:6627:1:vcl/source/window/errinf.cxx:177: Error not handled
I retrieved the bt from there if it can help.
Comment 6 Julien Nabet 2017-08-12 07:31:21 UTC
In lcl_showGeneralSfxErrorOnce (see https://opengrok.libreoffice.org/xref/core/sfx2/source/doc/docmacromode.cxx#86), I noticed this:
(gdb) p nSfxErrorCode
$12 = {m_value = 2147500084}
(gdb) p aErrorCodeRequest.ErrCode
$13 = -2147467212

In https://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/task/ErrorCodeRequest.idl, ErrCode is defined as a long.

Since 2147500084 > 2 power 31, the number is converted in negative.
Comment 7 Noel Grandin 2017-08-12 11:23:39 UTC
(In reply to Julien Nabet from comment #6)
> Since 2147500084 > 2 power 31, the number is converted in negative.

Yeah, thats fine, that is the way it has always been, we convert backwards and forwards but the bitpattern stays the same.

Perhaps you could convert that OSL_FAIL in errinf.cxx to

  SAL_WARN( "vcl", "Error not handled " << pInfo->GetErrorCode());

?
and see what error is being ignored?
Comment 8 Julien Nabet 2017-08-12 15:13:36 UTC
(In reply to Noel Grandin from comment #7)
> (In reply to Julien Nabet from comment #6)
> > Since 2147500084 > 2 power 31, the number is converted in negative.
> 
> Yeah, thats fine, that is the way it has always been, we convert backwards
> and forwards but the bitpattern stays the same.
Ok, I saw afterwards that negative values were dealt.

> Perhaps you could convert that OSL_FAIL in errinf.cxx to
> 
>   SAL_WARN( "vcl", "Error not handled " << pInfo->GetErrorCode());
> 
> ?
> and see what error is being ignored?
Here's the trace:
warn:vcl:13639:1:vcl/source/window/errinf.cxx:177: Error not handled 2147500084
this info + bt (frame 6 sfx2/source/doc/docmacromode.cxx:94), it seems to be ERRCODE_SFX_DOCUMENT_MACRO_DISABLED.

I submitted a patch to review here:
https://gerrit.libreoffice.org/#/c/41089/
Comment 9 Noel Grandin 2017-08-12 18:32:27 UTC
I have spotted one issue with my commit, fix here:
   https://gerrit.libreoffice.org/#/c/41096/
anybody care to test?
Comment 10 Julien Nabet 2017-08-12 18:45:51 UTC
(In reply to Noel Grandin from comment #9)
> I have spotted one issue with my commit, fix here:
>    https://gerrit.libreoffice.org/#/c/41096/
> anybody care to test?

Since this file is included in a lot of files, it's quite equivalent to build from scratch.
I propose you to push the patch if Jenkins doesn't complain about it. Indeed, it'll fix a bug fixed even it doesn't fix this bugtracker.

Once pushed, I'll update my local repo and launch a make clean && make
Comment 11 Julien Nabet 2017-08-12 18:57:24 UTC
Seeing https://opengrok.libreoffice.org/search?project=core&q=MakeWarning&defs=&refs=&path=&hist=&type=, the patch won't help.
But seeing the git history of these 2 files, the fix is correct, that's why I put +2 for code review.
Comment 12 Julien Nabet 2017-08-14 16:08:35 UTC
On pc Debian x86-64 with master sources updated today, I still reproduce this.
(and still see this on console:
warn:vcl:25837:1:vcl/source/window/errinf.cxx:177: Error not handled 2147500084)
Comment 13 Aron Budea 2017-08-15 00:13:39 UTC
The problem is with the construction of ERRCODE_SFX_DOCUMENT_MACRO_DISABLED (when it's actually substituted in RID_ERRHDL). Previously this had a nice value, something like 16436. Now it has that huge value, 2147500084, so when it looks for 16436, nothing is returned.

I couldn't identify why exactly the initialized value is different, possibly due to the change in type or something?
Comment 14 Noel Grandin 2017-08-15 09:29:43 UTC
Very weird.

ErrorResource::getString in uui/ is calling getRest on the passed in errorCode before comparing to the value in the array.

The other things that get passed to ErrorResource::getString, their definitions look like:

	{ NC_("RID_UUI_ERRHDL", "The operation executed on $(ARG1) was aborted."),
          ErrCode(sal_uInt32(ERRCODE_UUI_IO_ABORT) & ERRCODE_RES_MASK) },

but RID_ERRHDL in svtools/inc/errtxt.hrc does not, it looks like:

        { NC_("RID_ERRHDL", "An attempt was made to execute a macro.\nFor security reasons, macro support is disabled."),
          ErrCode(ERRCODE_SFX_MACROS_SUPPORT_DISABLED) },


Similarly SfxErrorHandler::GetErrorString in sfx2/source/appl/appinit.cxx is casting to sal_uInt16 which has much the same effect as calling getRest() or anding with ERRCODE_RES_MASK.

How this used to work I don't know, I suspect that somehow the value in the old .hrc file was being truncated to 16 bits.
Comment 15 Commit Notification 2017-08-15 16:32:50 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=26b97ba18e72f7c25c836177d895d429162a0120

tdf#111696 No macro security dialog with High setting

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Julien Nabet 2017-08-22 20:15:42 UTC
With master sources udpated today, I don't reproduce this.

Thank you Noel!