Re: Hyperlink Warning Message for mp4 file

[Arrigo Marchiori]

Hello,

On Mon, Aug 01, 2022 at 11:08:33PM +0200, Matthias Seidel wrote:

> Hi,
> 
> Am 01.08.22 um 20:20 schrieb Czesław Wolański:
> > Hi,
> >
> > The topic "Macro warning - sometimes" on the English forum, started
> > yesterday. [1]
> > An user annoyed by the fact that a hyperlink pointing to an mp4 file (as
> > opposed to an mp3 file)
> > raises a warning.
> >
> > As you all remember, the list of safe extensions was one of the issues
> > discussed
> > in the "Hyperlink Warning Message" thread on dev@.
> >
> > Shouldn't the mp4 extension be allowed?
> 
> We already allowed m4a. I don't think mp4 should be a problem?

PR open: https://github.com/apache/openoffice/pull/157

-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message for mp4 file

[Matthias Seidel]

Hi,

Am 01.08.22 um 20:20 schrieb Czesław Wolański:
> Hi,
>
> The topic "Macro warning - sometimes" on the English forum, started
> yesterday. [1]
> An user annoyed by the fact that a hyperlink pointing to an mp4 file (as
> opposed to an mp3 file)
> raises a warning.
>
> As you all remember, the list of safe extensions was one of the issues
> discussed
> in the "Hyperlink Warning Message" thread on dev@.
>
> Shouldn't the mp4 extension be allowed?

We already allowed m4a. I don't think mp4 should be a problem?

Regards,

   Matthias

>
>
>
> Best regards,
> Czesław
>
>
> [1]
> https://forum.openoffice.org/en/forum/viewtopic.php?t=108184
>
> [2]
> https://lists.apache.org/thread/pzlwfqzbxtllvrm6wlcmyc25fqzlofr2
>



smime.p7s
Description: S/MIME Cryptographic Signature

Hyperlink Warning Message for mp4 file

[Czesław Wolański]

Hi,

The topic "Macro warning - sometimes" on the English forum, started
yesterday. [1]
An user annoyed by the fact that a hyperlink pointing to an mp4 file (as
opposed to an mp3 file)
raises a warning.

As you all remember, the list of safe extensions was one of the issues
discussed
in the "Hyperlink Warning Message" thread on dev@.

Shouldn't the mp4 extension be allowed?



Best regards,
Czesław


[1]
https://forum.openoffice.org/en/forum/viewtopic.php?t=108184

[2]
https://lists.apache.org/thread/pzlwfqzbxtllvrm6wlcmyc25fqzlofr2

Re: Hyperlink Warning Message

[Arrigo Marchiori]

On Thu, Jun 24, 2021 at 11:21:49AM +0200, Matthias Seidel wrote:

> Hi all,
> 
> Find a Windows build here:
> 
> https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_f2fa887bab.exe

Thank you!

...also for updating the Bugzilla entry!

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi all,

Find a Windows build here:

https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_f2fa887bab.exe

Regards,

   Matthias

Am 24.06.21 um 03:17 schrieb Carl Marcum:
> Hi Arrigo,
>
> On 6/23/21 1:19 PM, Arrigo Marchiori wrote:
>> Dear All,
>>
>> On Tue, Jun 22, 2021 at 07:41:23PM +0200, Marcus wrote:
>>
>>> Am 22.06.21 um 19:26 schrieb Matthias Seidel:
 What about adding .wpl .m3u etc. to the list of secure file
 extensions?

 I would like to build a new version soon to let our users test...
>>> +1
>>>
>>> Marcus
>> I just uploaded a Linux build:
>> https://home.apache.org/~ardovm/openoffice/bug128453/2021-06-23/
>> It is in the "installed" format, i.e. it _should_ be executable right
>> after decompression.
>>
>> Sources are in the bug128453 branch (again):
>> https://github.com/apache/openoffice/tree/bug128453
>>
>> I also added the "ogg", "flac" and "m3u" extensions.
>>
>> For your kind testing.
>>
>> Best regards,
>
>
> Thanks for providing the "installed" type build.
> That makes it very easy to test.
>
> I tested the 3 new extensions you added with file:/// type links and
> all 3 were passed on to the OS.
> I think this now covers all the requests collected in bz from what I
> can tell.
>
> Thanks again for your work on this.
>
> Best regards,
> Carl
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Arrigo,

On 6/23/21 1:19 PM, Arrigo Marchiori wrote:

Dear All,

On Tue, Jun 22, 2021 at 07:41:23PM +0200, Marcus wrote:


Am 22.06.21 um 19:26 schrieb Matthias Seidel:

What about adding .wpl .m3u etc. to the list of secure file extensions?

I would like to build a new version soon to let our users test...

+1

Marcus

I just uploaded a Linux build:
https://home.apache.org/~ardovm/openoffice/bug128453/2021-06-23/
It is in the "installed" format, i.e. it _should_ be executable right
after decompression.

Sources are in the bug128453 branch (again):
https://github.com/apache/openoffice/tree/bug128453

I also added the "ogg", "flac" and "m3u" extensions.

For your kind testing.

Best regards,



Thanks for providing the "installed" type build.
That makes it very easy to test.

I tested the 3 new extensions you added with file:/// type links and all 
3 were passed on to the OS.
I think this now covers all the requests collected in bz from what I can 
tell.


Thanks again for your work on this.

Best regards,
Carl

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Arrigo,

Am 23.06.21 um 19:19 schrieb Arrigo Marchiori:
> Dear All,
>
> On Tue, Jun 22, 2021 at 07:41:23PM +0200, Marcus wrote:
>
>> Am 22.06.21 um 19:26 schrieb Matthias Seidel:
>>> What about adding .wpl .m3u etc. to the list of secure file extensions?
>>>
>>> I would like to build a new version soon to let our users test...
>> +1
>>
>> Marcus
> I just uploaded a Linux build:
> https://home.apache.org/~ardovm/openoffice/bug128453/2021-06-23/
> It is in the "installed" format, i.e. it _should_ be executable right
> after decompression.
>
> Sources are in the bug128453 branch (again):
> https://github.com/apache/openoffice/tree/bug128453
>
> I also added the "ogg", "flac" and "m3u" extensions.

Great! I will do a Windows build for interested users to test.

Regards,

   Matthias

>
> For your kind testing.
>
> Best regards,



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Dear All,

On Tue, Jun 22, 2021 at 07:41:23PM +0200, Marcus wrote:

> Am 22.06.21 um 19:26 schrieb Matthias Seidel:
> > What about adding .wpl .m3u etc. to the list of secure file extensions?
> > 
> > I would like to build a new version soon to let our users test...
> 
> +1
> 
> Marcus

I just uploaded a Linux build:
https://home.apache.org/~ardovm/openoffice/bug128453/2021-06-23/
It is in the "installed" format, i.e. it _should_ be executable right
after decompression.

Sources are in the bug128453 branch (again):
https://github.com/apache/openoffice/tree/bug128453

I also added the "ogg", "flac" and "m3u" extensions.

For your kind testing.

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Marcus]

Am 22.06.21 um 19:26 schrieb Matthias Seidel:

What about adding .wpl .m3u etc. to the list of secure file extensions?

I would like to build a new version soon to let our users test...


+1

Marcus




Am 15.06.21 um 18:36 schrieb Matthias Seidel:

Am 15.06.21 um 18:34 schrieb Marcus:

Am 14.06.21 um 17:46 schrieb Matthias Seidel:

Am 14.06.21 um 17:39 schrieb Marcus:

Am 14.06.21 um 16:58 schrieb Arrigo Marchiori:

the original poster of bug 128453 correctly noted that the bug was not
solved _for him_: https://bz.apache.org/ooo/show_bug.cgi?id=128453#c9

In his case, AOO is showing a warning when he tries to open a WPL
file, that is a Windows Media Player playlist:
https://en.wikipedia.org/wiki/Windows_Media_Player_Playlist

Shall we just add it to the list of safe extensions, to solve the
problem?

IMHO we have to be very careful where we draw the line.
Who shoud decide what is on the list and what not?

That's why Arrigo asked here, I think.

When we allow WPL, what about ASX, M3U and other music playlist files?

IMHO they should also be allowed. AOO only passes them to the
player/CODEC of the OS.

would be OK.


And do we want to create always a new release to add something new in
the internal whitelist? ;-)

No, at the moment we want to create a new release based on the feedback
of our users... ;-)

Yes sure, and with a new issue comes a new request and therefore a new
release. ;-)

That's the way how a project like ours is maintained...



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi all,

What about adding .wpl .m3u etc. to the list of secure file extensions?

I would like to build a new version soon to let our users test...

Regards,

   Matthias

Am 15.06.21 um 18:36 schrieb Matthias Seidel:
> Hi Marcus,
>
> Am 15.06.21 um 18:34 schrieb Marcus:
>> Am 14.06.21 um 17:46 schrieb Matthias Seidel:
>>> Am 14.06.21 um 17:39 schrieb Marcus:
 Am 14.06.21 um 16:58 schrieb Arrigo Marchiori:
> the original poster of bug 128453 correctly noted that the bug was not
> solved _for him_: https://bz.apache.org/ooo/show_bug.cgi?id=128453#c9
>
> In his case, AOO is showing a warning when he tries to open a WPL
> file, that is a Windows Media Player playlist:
> https://en.wikipedia.org/wiki/Windows_Media_Player_Playlist
>
> Shall we just add it to the list of safe extensions, to solve the
> problem?
 IMHO we have to be very careful where we draw the line.
 Who shoud decide what is on the list and what not?
>>> That's why Arrigo asked here, I think.
 When we allow WPL, what about ASX, M3U and other music playlist files?
>>> IMHO they should also be allowed. AOO only passes them to the
>>> player/CODEC of the OS.
>> would be OK.
>>
 And do we want to create always a new release to add something new in
 the internal whitelist? ;-)
>>> No, at the moment we want to create a new release based on the feedback
>>> of our users... ;-)
>> Yes sure, and with a new issue comes a new request and therefore a new
>> release. ;-)
> That's the way how a project like ours is maintained...
>
> Matthias
>
>> Marcus
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Marcus,

Am 15.06.21 um 18:34 schrieb Marcus:
> Am 14.06.21 um 17:46 schrieb Matthias Seidel:
>> Am 14.06.21 um 17:39 schrieb Marcus:
>>> Am 14.06.21 um 16:58 schrieb Arrigo Marchiori:
 the original poster of bug 128453 correctly noted that the bug was not
 solved _for him_: https://bz.apache.org/ooo/show_bug.cgi?id=128453#c9

 In his case, AOO is showing a warning when he tries to open a WPL
 file, that is a Windows Media Player playlist:
 https://en.wikipedia.org/wiki/Windows_Media_Player_Playlist

 Shall we just add it to the list of safe extensions, to solve the
 problem?
>>>
>>> IMHO we have to be very careful where we draw the line.
>>> Who shoud decide what is on the list and what not?
>> That's why Arrigo asked here, I think.
>>>
>>> When we allow WPL, what about ASX, M3U and other music playlist files?
>> IMHO they should also be allowed. AOO only passes them to the
>> player/CODEC of the OS.
>
> would be OK.
>
>>> And do we want to create always a new release to add something new in
>>> the internal whitelist? ;-)
>>
>> No, at the moment we want to create a new release based on the feedback
>> of our users... ;-)
>
> Yes sure, and with a new issue comes a new request and therefore a new
> release. ;-)

That's the way how a project like ours is maintained...

Matthias

>
> Marcus
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Marcus]

Am 14.06.21 um 17:46 schrieb Matthias Seidel:

Am 14.06.21 um 17:39 schrieb Marcus:

Am 14.06.21 um 16:58 schrieb Arrigo Marchiori:

the original poster of bug 128453 correctly noted that the bug was not
solved _for him_: https://bz.apache.org/ooo/show_bug.cgi?id=128453#c9

In his case, AOO is showing a warning when he tries to open a WPL
file, that is a Windows Media Player playlist:
https://en.wikipedia.org/wiki/Windows_Media_Player_Playlist

Shall we just add it to the list of safe extensions, to solve the
problem?


IMHO we have to be very careful where we draw the line.
Who shoud decide what is on the list and what not?

That's why Arrigo asked here, I think.


When we allow WPL, what about ASX, M3U and other music playlist files?

IMHO they should also be allowed. AOO only passes them to the
player/CODEC of the OS.


would be OK.


And do we want to create always a new release to add something new in
the internal whitelist? ;-)


No, at the moment we want to create a new release based on the feedback
of our users... ;-)


Yes sure, and with a new issue comes a new request and therefore a new 
release. ;-)


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi,

Am 14.06.21 um 17:39 schrieb Marcus:
> Am 14.06.21 um 16:58 schrieb Arrigo Marchiori:
>> the original poster of bug 128453 correctly noted that the bug was not
>> solved _for him_: https://bz.apache.org/ooo/show_bug.cgi?id=128453#c9
>>
>> In his case, AOO is showing a warning when he tries to open a WPL
>> file, that is a Windows Media Player playlist:
>> https://en.wikipedia.org/wiki/Windows_Media_Player_Playlist
>>
>> Shall we just add it to the list of safe extensions, to solve the
>> problem?
>
> IMHO we have to be very careful where we draw the line.
> Who shoud decide what is on the list and what not?
That's why Arrigo asked here, I think.
>
> When we allow WPL, what about ASX, M3U and other music playlist files?
IMHO they should also be allowed. AOO only passes them to the
player/CODEC of the OS.
> And do we want to create always a new release to add something new in
> the internal whitelist? ;-)

No, at the moment we want to create a new release based on the feedback
of our users... ;-)

Matthias

>
> Marcus
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Marcus]

Am 14.06.21 um 16:58 schrieb Arrigo Marchiori:

the original poster of bug 128453 correctly noted that the bug was not
solved _for him_: https://bz.apache.org/ooo/show_bug.cgi?id=128453#c9

In his case, AOO is showing a warning when he tries to open a WPL
file, that is a Windows Media Player playlist:
https://en.wikipedia.org/wiki/Windows_Media_Player_Playlist

Shall we just add it to the list of safe extensions, to solve the
problem?


IMHO we have to be very careful where we draw the line.
Who shoud decide what is on the list and what not?

When we allow WPL, what about ASX, M3U and other music playlist files?

And do we want to create always a new release to add something new in 
the internal whitelist? ;-)


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Dear All,

the original poster of bug 128453 correctly noted that the bug was not
solved _for him_: https://bz.apache.org/ooo/show_bug.cgi?id=128453#c9

In his case, AOO is showing a warning when he tries to open a WPL
file, that is a Windows Media Player playlist:
https://en.wikipedia.org/wiki/Windows_Media_Player_Playlist

Shall we just add it to the list of safe extensions, to solve the
problem?

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Marcus,

Am 14.06.21 um 15:58 schrieb Marcus:
> Am 12.06.21 um 03:47 schrieb Carl Marcum:
>> On 6/11/21 6:19 PM, Matthias Seidel wrote:
>>> Am 10.06.21 um 15:53 schrieb Matthias Seidel:

 Could you provide a test document?

 Or (if you use Windows) make a test with this build:

 https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe

>>> I posted the wrong link for the build, please try this one:
>>>
>>> https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe
>>>
>> This one works great on my test document!
>> No warning on the .uno:Reload button or the odf file or
>> inter-document links.
>>
>> I did discover a bug unrelated to this.
>>
>> When I open the document I created on Linux with the hyperlinks and
>> uno button using the file open dialog it opens correctly using
>> Windows 10.
>> When I open it again using dropdown beside the Open button in the
>> Start Center or File > Recent Documents I get an ASCII Filter Options
>> dialog and then a General Error. General input/output error and the
>> file doesn't open.
>>
>> Also happens with a production 4.1.9 that was on this system I'm
>> testing on.
>>
>> Can anyone on windows confirm with the file [1]?
>> [1]
>> http://home.apache.org/~cmarcum/hyperlink-tests/hyperlink-test-doc.odt
>
> thanks for this document.
>
> I've tested it with Matthias' AOO 4.1.11 build on Win 10 and can
> confirm the behavior for showing resp. not showing the warning dialog;
> especially for the Reload-button (URL: .uno:reload).
>
> @Matthias:
> I've installed the AOO 4.1.11_807d57542e.exe (from 2021-06-13). The
> file from the above URL above was not available, so I hope this is OK.

Yes, that build supersedes the older version.

Matthias

>
> Marcus
>
>
>
 Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
> For some years I've had a Reload button in my Calc document to
> avoid having to use the File menu. Just updated to 4.1.10 and now
> I get a message when pressing Reload button:
>
> This hyperlink is going to open “.uno:Reload”. Do you want to
> proceed?
>
> Is there a way of switching off this message please?
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Marcus]

Am 12.06.21 um 03:47 schrieb Carl Marcum:

On 6/11/21 6:19 PM, Matthias Seidel wrote:

Am 10.06.21 um 15:53 schrieb Matthias Seidel:


Could you provide a test document?

Or (if you use Windows) make a test with this build:

https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe 


I posted the wrong link for the build, please try this one:

https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe 


This one works great on my test document!
No warning on the .uno:Reload button or the odf file or inter-document 
links.


I did discover a bug unrelated to this.

When I open the document I created on Linux with the hyperlinks and uno 
button using the file open dialog it opens correctly using Windows 10.
When I open it again using dropdown beside the Open button in the Start 
Center or File > Recent Documents I get an ASCII Filter Options dialog 
and then a General Error. General input/output error and the file 
doesn't open.


Also happens with a production 4.1.9 that was on this system I'm testing 
on.


Can anyone on windows confirm with the file [1]?
[1] http://home.apache.org/~cmarcum/hyperlink-tests/hyperlink-test-doc.odt


thanks for this document.

I've tested it with Matthias' AOO 4.1.11 build on Win 10 and can confirm 
the behavior for showing resp. not showing the warning dialog; 
especially for the Reload-button (URL: .uno:reload).


@Matthias:
I've installed the AOO 4.1.11_807d57542e.exe (from 2021-06-13). The file 
from the above URL above was not available, so I hope this is OK.


Marcus




Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
For some years I've had a Reload button in my Calc document to avoid 
having to use the File menu. Just updated to 4.1.10 and now I get a 
message when pressing Reload button:


This hyperlink is going to open “.uno:Reload”. Do you want to proceed?

Is there a way of switching off this message please?



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Hello Matthias, all,

On Sat, Jun 12, 2021 at 08:00:52PM +0200, Matthias Seidel wrote:

> Hi Pedro,
> 
> Am 12.06.21 um 19:55 schrieb Pedro Lino:
> > Hi Carl
> >
> >> On 06/12/2021 6:45 PM Carl Marcum  wrote:
> >> There is now a PR #132 if you're able to test it.
> > What do you mean test the PR? I already tested the resulting binary...
> The Windows binary... ;-)
> >
> > The only action available for me at github is "Merge pull request" :)
> 
> You can build your own version with:
> 
> git fetch origin pull/132/head:pr132
> 
> That creates a local branch pr132.
> 
> We still need versions for Linux and macOS for testing.

I prepared deb's and RPM's for Linux in the en-US language:
http://home.apache.org/~ardovm/openoffice/bug128453/2021-06-05/

Today's commits did not change the code since that snapshot.

I hope this helps.

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Pedro,

Am 12.06.21 um 19:55 schrieb Pedro Lino:
> Hi Carl
>
>> On 06/12/2021 6:45 PM Carl Marcum  wrote:
>> There is now a PR #132 if you're able to test it.
> What do you mean test the PR? I already tested the resulting binary...
The Windows binary... ;-)
>
> The only action available for me at github is "Merge pull request" :)

You can build your own version with:

git fetch origin pull/132/head:pr132

That creates a local branch pr132.

We still need versions for Linux and macOS for testing.

Regards,

   Matthias

>
> Cheers,
> Pedro
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Pedro Lino]

Hi Carl

> On 06/12/2021 6:45 PM Carl Marcum  wrote:

> There is now a PR #132 if you're able to test it.

What do you mean test the PR? I already tested the resulting binary...

The only action available for me at github is "Merge pull request" :)

Cheers,
Pedro

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Pedro,

On 6/12/21 12:22 PM, Pedro Lino wrote:

Hi Carl, all


On 06/12/2021 2:47 AM Carl Marcum  wrote:
Can anyone on windows confirm with the file [1]?
[1] http://home.apache.org/~cmarcum/hyperlink-tests/hyperlink-test-doc.odt

I confirm Francis' findings on AOO 4.1.11 running on Windows 7 x64.
There is no problem reopening the document.


Thanks for testing!


I can also confirm that all links in the document behave as expected under AOO 
4.1.11, with warnings only on untrusted links.


Yes very good news.

There is now a PR #132 if you're able to test it.

Best regards,
Carl


All good news ;)

Cheers,
Pedro

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Pedro Lino]

Hi Carl, all

> On 06/12/2021 2:47 AM Carl Marcum  wrote:

> Can anyone on windows confirm with the file [1]?
> [1] http://home.apache.org/~cmarcum/hyperlink-tests/hyperlink-test-doc.odt

I confirm Francis' findings on AOO 4.1.11 running on Windows 7 x64.
There is no problem reopening the document.

I can also confirm that all links in the document behave as expected under AOO 
4.1.11, with warnings only on untrusted links.

All good news ;)

Cheers,
Pedro

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Arrigo,

Am 12.06.21 um 15:01 schrieb Arrigo Marchiori:
> Hello all,
>
> On Sat, Jun 12, 2021 at 01:42:19PM +0200, Matthias Seidel wrote:
>
>> Hi Carl,
>>
>> Am 12.06.21 um 13:26 schrieb Carl Marcum:
>>> Hi Matthias,
>>>
>>> On 6/12/21 5:10 AM, Matthias Seidel wrote:
 Hi Carl, all,

 Tests look great and we should think about merging the fix into the
 official AOO4111 branch.
>>> Yes merge it in AOO41X and branch from it.
>>>
>>> Yes I think it's ready for trunk and AOO42X also.
>>> Maybe we wait for the other two until we have more widespread testing
>>> but this seems like the right fix to me.
>> I would like to leave that to Arrigo since the build is based on his branch.
> Thank you. I would like to clean the history a bit before merging it.
>
>> We should definitely merge to trunk/AOO42X and then to AOO41X.
> In fact I branched from AOO41X therefore the easiest step will be to
> merge it to AOO41X first. Then I could cherry-pick it into trunk, and
> then merge it into AOO42X. Would this be acceptable, or shall I merge
> the commits in the order you are suggesting?
>
> To summarize. My suggestion:
>  1- merge into AOO41X
>  2- cherry-pick into trunk
>  3- merge into AOO42X
>
> Your suggestion:
>  1- cherry-pick into trunk
>  2- merge into AOO42X
>  3- merge into AOO41X.
>
> I am looking forward to your indications in order to do the merge.

I don't know if it really makes a difference. Your suggestion looks OK
for me!

Regards,

   Matthias

>
> Best regards,



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Hello all,

On Sat, Jun 12, 2021 at 01:42:19PM +0200, Matthias Seidel wrote:

> Hi Carl,
> 
> Am 12.06.21 um 13:26 schrieb Carl Marcum:
> > Hi Matthias,
> >
> > On 6/12/21 5:10 AM, Matthias Seidel wrote:
> >> Hi Carl, all,
> >>
> >> Tests look great and we should think about merging the fix into the
> >> official AOO4111 branch.
> > Yes merge it in AOO41X and branch from it.
> >
> > Yes I think it's ready for trunk and AOO42X also.
> > Maybe we wait for the other two until we have more widespread testing
> > but this seems like the right fix to me.
> 
> I would like to leave that to Arrigo since the build is based on his branch.

Thank you. I would like to clean the history a bit before merging it.

> We should definitely merge to trunk/AOO42X and then to AOO41X.

In fact I branched from AOO41X therefore the easiest step will be to
merge it to AOO41X first. Then I could cherry-pick it into trunk, and
then merge it into AOO42X. Would this be acceptable, or shall I merge
the commits in the order you are suggesting?

To summarize. My suggestion:
 1- merge into AOO41X
 2- cherry-pick into trunk
 3- merge into AOO42X

Your suggestion:
 1- cherry-pick into trunk
 2- merge into AOO42X
 3- merge into AOO41X.

I am looking forward to your indications in order to do the merge.

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Carl,

Am 12.06.21 um 13:26 schrieb Carl Marcum:
> Hi Matthias,
>
> On 6/12/21 5:10 AM, Matthias Seidel wrote:
>> Hi Carl, all,
>>
>> Tests look great and we should think about merging the fix into the
>> official AOO4111 branch.
> Yes merge it in AOO41X and branch from it.
>
> Yes I think it's ready for trunk and AOO42X also.
> Maybe we wait for the other two until we have more widespread testing
> but this seems like the right fix to me.

I would like to leave that to Arrigo since the build is based on his branch.

We should definitely merge to trunk/AOO42X and then to AOO41X.

Regards,

   Matthias

>
> Best regards,
> Carl
>
>>
>> Additionally we could need test builds for mac and Linux.
>>
>> Regards,
>>
>>     Matthias
>>
>> Am 12.06.21 um 03:47 schrieb Carl Marcum:
>>> Hi Matthias,
>>>
>>> On 6/11/21 6:19 PM, Matthias Seidel wrote:
 Hi Keith, all,

 Am 10.06.21 um 15:53 schrieb Matthias Seidel:
> Hi Keith,
>
> Could you provide a test document?
>
> Or (if you use Windows) make a test with this build:
>
> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe
>
>
 I posted the wrong link for the build, please try this one:

 https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe



 Regards,

  Matthias
>>> This one works great on my test document!
>>> No warning on the .uno:Reload button or the odf file or inter-document
>>> links.
>>>
>>> I did discover a bug unrelated to this.
>>>
>>> When I open the document I created on Linux with the hyperlinks and
>>> uno button using the file open dialog it opens correctly using Windows
>>> 10.
>>> When I open it again using dropdown beside the Open button in the
>>> Start Center or File > Recent Documents I get an ASCII Filter Options
>>> dialog and then a General Error. General input/output error and the
>>> file doesn't open.
>>>
>>> Also happens with a production 4.1.9 that was on this system I'm
>>> testing on.
>>>
>>> Can anyone on windows confirm with the file [1]?
>>> [1]
>>> http://home.apache.org/~cmarcum/hyperlink-tests/hyperlink-test-doc.odt
>>>
>>>
>>> Thanks,
>>> Carl
> Regards,
>
>  Matthias
>
> Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
>> For some years I've had a Reload button in my Calc document to
>> avoid having to use the File menu. Just updated to 4.1.10 and now I
>> get a message when pressing Reload button:
>>
>> This hyperlink is going to open “.uno:Reload”. Do you want to
>> proceed?
>>
>> Is there a way of switching off this message please?
>>
>> Thanks.
>>
>> Regards
>> Keith Shelton
>>
>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Matthias,

On 6/12/21 5:10 AM, Matthias Seidel wrote:

Hi Carl, all,

Tests look great and we should think about merging the fix into the
official AOO4111 branch.

Yes merge it in AOO41X and branch from it.

Yes I think it's ready for trunk and AOO42X also.
Maybe we wait for the other two until we have more widespread testing 
but this seems like the right fix to me.


Best regards,
Carl



Additionally we could need test builds for mac and Linux.

Regards,

    Matthias

Am 12.06.21 um 03:47 schrieb Carl Marcum:

Hi Matthias,

On 6/11/21 6:19 PM, Matthias Seidel wrote:

Hi Keith, all,

Am 10.06.21 um 15:53 schrieb Matthias Seidel:

Hi Keith,

Could you provide a test document?

Or (if you use Windows) make a test with this build:

https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe


I posted the wrong link for the build, please try this one:

https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe


Regards,

     Matthias

This one works great on my test document!
No warning on the .uno:Reload button or the odf file or inter-document
links.

I did discover a bug unrelated to this.

When I open the document I created on Linux with the hyperlinks and
uno button using the file open dialog it opens correctly using Windows
10.
When I open it again using dropdown beside the Open button in the
Start Center or File > Recent Documents I get an ASCII Filter Options
dialog and then a General Error. General input/output error and the
file doesn't open.

Also happens with a production 4.1.9 that was on this system I'm
testing on.

Can anyone on windows confirm with the file [1]?
[1]
http://home.apache.org/~cmarcum/hyperlink-tests/hyperlink-test-doc.odt


Thanks,
Carl

Regards,

     Matthias

Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:

For some years I've had a Reload button in my Calc document to
avoid having to use the File menu. Just updated to 4.1.10 and now I
get a message when pressing Reload button:

This hyperlink is going to open “.uno:Reload”. Do you want to proceed?

Is there a way of switching off this message please?

Thanks.

Regards
Keith Shelton




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Francis,

On 6/11/21 11:31 PM, F Campos Costero wrote:

I downloaded the test document and tried the links using 4.1.10. I saw the
expected warnings. Closing the file and reopening via the drop down list on
the Open button worked with no problem. I then installed the 4.1.11 linked
above (Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe
)
and repeated the test, again with no problems when I reopened the
document.  I did not try all of the links in the document but I did try at
least one of each kind.
Is that the kind of test you needed?


Yes that's just what I needed.
That tells me it may just be machine specific and not easy to reproduce.

Thanks for your test!

Best regards,
Carl


I am on Windows 10 and ran the
2021-06 update yesterday.

Francis

On Fri, Jun 11, 2021 at 7:47 PM Carl Marcum  wrote:


Hi Matthias,

On 6/11/21 6:19 PM, Matthias Seidel wrote:

Hi Keith, all,

Am 10.06.21 um 15:53 schrieb Matthias Seidel:

Hi Keith,

Could you provide a test document?

Or (if you use Windows) make a test with this build:



https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe

I posted the wrong link for the build, please try this one:



https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe

Regards,

 Matthias

This one works great on my test document!
No warning on the .uno:Reload button or the odf file or inter-document
links.

I did discover a bug unrelated to this.

When I open the document I created on Linux with the hyperlinks and uno
button using the file open dialog it opens correctly using Windows 10.
When I open it again using dropdown beside the Open button in the Start
Center or File > Recent Documents I get an ASCII Filter Options dialog
and then a General Error. General input/output error and the file
doesn't open.

Also happens with a production 4.1.9 that was on this system I'm testing
on.

Can anyone on windows confirm with the file [1]?
[1] http://home.apache.org/~cmarcum/hyperlink-tests/hyperlink-test-doc.odt


Thanks,
Carl

Regards,

 Matthias

Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:

For some years I've had a Reload button in my Calc document to avoid

having to use the File menu. Just updated to 4.1.10 and now I get a message
when pressing Reload button:

This hyperlink is going to open “.uno:Reload”. Do you want to proceed?

Is there a way of switching off this message please?

Thanks.

Regards
Keith Shelton




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Carl, all,

Tests look great and we should think about merging the fix into the
official AOO4111 branch.

Additionally we could need test builds for mac and Linux.

Regards,

   Matthias

Am 12.06.21 um 03:47 schrieb Carl Marcum:
> Hi Matthias,
>
> On 6/11/21 6:19 PM, Matthias Seidel wrote:
>> Hi Keith, all,
>>
>> Am 10.06.21 um 15:53 schrieb Matthias Seidel:
>>> Hi Keith,
>>>
>>> Could you provide a test document?
>>>
>>> Or (if you use Windows) make a test with this build:
>>>
>>> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe
>>>
>> I posted the wrong link for the build, please try this one:
>>
>> https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe
>>
>>
>> Regards,
>>
>>     Matthias
>
> This one works great on my test document!
> No warning on the .uno:Reload button or the odf file or inter-document
> links.
>
> I did discover a bug unrelated to this.
>
> When I open the document I created on Linux with the hyperlinks and
> uno button using the file open dialog it opens correctly using Windows
> 10.
> When I open it again using dropdown beside the Open button in the
> Start Center or File > Recent Documents I get an ASCII Filter Options
> dialog and then a General Error. General input/output error and the
> file doesn't open.
>
> Also happens with a production 4.1.9 that was on this system I'm
> testing on.
>
> Can anyone on windows confirm with the file [1]?
> [1]
> http://home.apache.org/~cmarcum/hyperlink-tests/hyperlink-test-doc.odt
>
>
> Thanks,
> Carl
>>
>>> Regards,
>>>
>>>     Matthias
>>>
>>> Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
 For some years I've had a Reload button in my Calc document to
 avoid having to use the File menu. Just updated to 4.1.10 and now I
 get a message when pressing Reload button:

 This hyperlink is going to open “.uno:Reload”. Do you want to proceed?

 Is there a way of switching off this message please?

 Thanks.

 Regards
 Keith Shelton


>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[F Campos Costero]

I downloaded the test document and tried the links using 4.1.10. I saw the
expected warnings. Closing the file and reopening via the drop down list on
the Open button worked with no problem. I then installed the 4.1.11 linked
above (Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe
)
and repeated the test, again with no problems when I reopened the
document.  I did not try all of the links in the document but I did try at
least one of each kind.
Is that the kind of test you needed?  I am on Windows 10 and ran the
2021-06 update yesterday.

Francis

On Fri, Jun 11, 2021 at 7:47 PM Carl Marcum  wrote:

> Hi Matthias,
>
> On 6/11/21 6:19 PM, Matthias Seidel wrote:
> > Hi Keith, all,
> >
> > Am 10.06.21 um 15:53 schrieb Matthias Seidel:
> >> Hi Keith,
> >>
> >> Could you provide a test document?
> >>
> >> Or (if you use Windows) make a test with this build:
> >>
> >>
> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe
> > I posted the wrong link for the build, please try this one:
> >
> >
> https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe
> >
> > Regards,
> >
> > Matthias
>
> This one works great on my test document!
> No warning on the .uno:Reload button or the odf file or inter-document
> links.
>
> I did discover a bug unrelated to this.
>
> When I open the document I created on Linux with the hyperlinks and uno
> button using the file open dialog it opens correctly using Windows 10.
> When I open it again using dropdown beside the Open button in the Start
> Center or File > Recent Documents I get an ASCII Filter Options dialog
> and then a General Error. General input/output error and the file
> doesn't open.
>
> Also happens with a production 4.1.9 that was on this system I'm testing
> on.
>
> Can anyone on windows confirm with the file [1]?
> [1] http://home.apache.org/~cmarcum/hyperlink-tests/hyperlink-test-doc.odt
>
>
> Thanks,
> Carl
> >
> >> Regards,
> >>
> >> Matthias
> >>
> >> Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
> >>> For some years I've had a Reload button in my Calc document to avoid
> having to use the File menu. Just updated to 4.1.10 and now I get a message
> when pressing Reload button:
> >>>
> >>> This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
> >>>
> >>> Is there a way of switching off this message please?
> >>>
> >>> Thanks.
> >>>
> >>> Regards
> >>> Keith Shelton
> >>>
> >>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Matthias,

On 6/11/21 6:19 PM, Matthias Seidel wrote:

Hi Keith, all,

Am 10.06.21 um 15:53 schrieb Matthias Seidel:

Hi Keith,

Could you provide a test document?

Or (if you use Windows) make a test with this build:

https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe

I posted the wrong link for the build, please try this one:

https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe

Regards,

    Matthias


This one works great on my test document!
No warning on the .uno:Reload button or the odf file or inter-document 
links.


I did discover a bug unrelated to this.

When I open the document I created on Linux with the hyperlinks and uno 
button using the file open dialog it opens correctly using Windows 10.
When I open it again using dropdown beside the Open button in the Start 
Center or File > Recent Documents I get an ASCII Filter Options dialog 
and then a General Error. General input/output error and the file 
doesn't open.


Also happens with a production 4.1.9 that was on this system I'm testing on.

Can anyone on windows confirm with the file [1]?
[1] http://home.apache.org/~cmarcum/hyperlink-tests/hyperlink-test-doc.odt


Thanks,
Carl



Regards,

    Matthias

Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:

For some years I've had a Reload button in my Calc document to avoid having to 
use the File menu. Just updated to 4.1.10 and now I get a message when pressing 
Reload button:

This hyperlink is going to open “.uno:Reload”. Do you want to proceed?

Is there a way of switching off this message please?

Thanks.

Regards
Keith Shelton





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Keith, all,

Am 10.06.21 um 15:53 schrieb Matthias Seidel:
> Hi Keith,
>
> Could you provide a test document?
>
> Or (if you use Windows) make a test with this build:
>
> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe
I posted the wrong link for the build, please try this one:

https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe

Regards,

   Matthias

>
> Regards,
>
>    Matthias
>
> Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
>> For some years I've had a Reload button in my Calc document to avoid having 
>> to use the File menu. Just updated to 4.1.10 and now I get a message when 
>> pressing Reload button: 
>>
>> This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
>>
>> Is there a way of switching off this message please?
>>
>> Thanks.
>>
>> Regards
>> Keith Shelton
>>
>>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Carl,

Am 12.06.21 um 00:12 schrieb Carl Marcum:
> Hi Matthias,
>
> On 6/11/21 5:05 PM, Matthias Seidel wrote:
>> Hi Carl,
>>
>> Am 11.06.21 um 23:01 schrieb Carl Marcum:
>>> Hi Matthias,
>>>
>>> On 6/10/21 9:53 AM, Matthias Seidel wrote:
 Hi Keith,

 Could you provide a test document?

 Or (if you use Windows) make a test with this build:

 https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe


>>> Was this 4.2 build supposed to have the .uno: hyperlink fixed so the
>>> warning doesn't display?
>> No, this one is based on Arrigo's branch:
>>
>> https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe
>>
>>
>> Regards,
>>
>>     Matthias
> Sorry, since you asked Keith Shelton to test it and that was his
> problem I thought you may have patched it.

Oh, that was clearly a wrong cut and paste from me! Maybe too late at
night... ;-)

The 4111 nuild is the right one!

Regards,

   Matthias

>
> So I tried it :)
>
> Thanks for building!
> Carl
>>> My test still has the warning.
>>>
>>> Thanks,
>>> Carl
>>>
 Regards,

  Matthias

 Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
> For some years I've had a Reload button in my Calc document to avoid
> having to use the File menu. Just updated to 4.1.10 and now I get a
> message when pressing Reload button:
>
> This hyperlink is going to open “.uno:Reload”. Do you want to
> proceed?
>
> Is there a way of switching off this message please?
>
> Thanks.
>
> Regards
> Keith Shelton
>
>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Matthias,

On 6/11/21 5:05 PM, Matthias Seidel wrote:

Hi Carl,

Am 11.06.21 um 23:01 schrieb Carl Marcum:

Hi Matthias,

On 6/10/21 9:53 AM, Matthias Seidel wrote:

Hi Keith,

Could you provide a test document?

Or (if you use Windows) make a test with this build:

https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe


Was this 4.2 build supposed to have the .uno: hyperlink fixed so the
warning doesn't display?

No, this one is based on Arrigo's branch:

https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe

Regards,

    Matthias
Sorry, since you asked Keith Shelton to test it and that was his problem 
I thought you may have patched it.


So I tried it :)

Thanks for building!
Carl

My test still has the warning.

Thanks,
Carl


Regards,

     Matthias

Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:

For some years I've had a Reload button in my Calc document to avoid
having to use the File menu. Just updated to 4.1.10 and now I get a
message when pressing Reload button:

This hyperlink is going to open “.uno:Reload”. Do you want to proceed?

Is there a way of switching off this message please?

Thanks.

Regards
Keith Shelton




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Keith,

Am 11.06.21 um 21:24 schrieb Keith N. McKenna:
> On 2021-06-10 09:53, Matthias Seidel wrote:
>> Hi Keith,
>>
>> Could you provide a test document?
>>
>> Or (if you use Windows) make a test with this build:
>>
>> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe
>>
>> Regards,
>>
>>    Matthias
>>
>> Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
>>> For some years I've had a Reload button in my Calc document to avoid having 
>>> to use the File menu. Just updated to 4.1.10 and now I get a message when 
>>> pressing Reload button: 
>>>
>>> This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
>>>
>>> Is there a way of switching off this message please?
>>>
>>> Thanks.
>>>
>>> Regards
>>> Keith Shelton
>>>
>>>
> Hi Matthias;
>
> Unfortunately I cannot as Windows 10 is playing stupid as usual. I
> cannot unpack it to my test folder, as 4.2.0 Dev Build 2 is on the
> system and AOO rejects the Test build as the Dev-build is considered a
> higher revision.
In fact my mail was for Keith Shelton, who did provide me a test
document now.
>
> With some of the latest updates I can no longer unpack it to my NAS
> drive. I am Leaving Sunday for a week at Conception Abbey in Missouri
> and will not be back until a week from Saturday when I will have time to
> threaten the system with bodily harm and get at least one one method to
> work.

Let me know if I can help you with parallel Windows installation when
you are back!

Regards,

   Matthias

>
> Regards
> Keith
>
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Carl,

Am 11.06.21 um 23:01 schrieb Carl Marcum:
> Hi Matthias,
>
> On 6/10/21 9:53 AM, Matthias Seidel wrote:
>> Hi Keith,
>>
>> Could you provide a test document?
>>
>> Or (if you use Windows) make a test with this build:
>>
>> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe
>>
>
> Was this 4.2 build supposed to have the .uno: hyperlink fixed so the
> warning doesn't display?

No, this one is based on Arrigo's branch:

https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe

Regards,

   Matthias

>
> My test still has the warning.
>
> Thanks,
> Carl
>
>>
>> Regards,
>>
>>     Matthias
>>
>> Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
>>> For some years I've had a Reload button in my Calc document to avoid
>>> having to use the File menu. Just updated to 4.1.10 and now I get a
>>> message when pressing Reload button:
>>>
>>> This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
>>>
>>> Is there a way of switching off this message please?
>>>
>>> Thanks.
>>>
>>> Regards
>>> Keith Shelton
>>>
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Matthias,

On 6/10/21 9:53 AM, Matthias Seidel wrote:

Hi Keith,

Could you provide a test document?

Or (if you use Windows) make a test with this build:

https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe


Was this 4.2 build supposed to have the .uno: hyperlink fixed so the 
warning doesn't display?


My test still has the warning.

Thanks,
Carl



Regards,

    Matthias

Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:

For some years I've had a Reload button in my Calc document to avoid having to 
use the File menu. Just updated to 4.1.10 and now I get a message when pressing 
Reload button:

This hyperlink is going to open “.uno:Reload”. Do you want to proceed?

Is there a way of switching off this message please?

Thanks.

Regards
Keith Shelton





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Keith N. McKenna]

On 2021-06-10 09:53, Matthias Seidel wrote:
> Hi Keith,
> 
> Could you provide a test document?
> 
> Or (if you use Windows) make a test with this build:
> 
> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe
> 
> Regards,
> 
>    Matthias
> 
> Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
>> For some years I've had a Reload button in my Calc document to avoid having 
>> to use the File menu. Just updated to 4.1.10 and now I get a message when 
>> pressing Reload button: 
>>
>> This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
>>
>> Is there a way of switching off this message please?
>>
>> Thanks.
>>
>> Regards
>> Keith Shelton
>>
>>
> 
Hi Matthias;

Unfortunately I cannot as Windows 10 is playing stupid as usual. I
cannot unpack it to my test folder, as 4.2.0 Dev Build 2 is on the
system and AOO rejects the Test build as the Dev-build is considered a
higher revision.

With some of the latest updates I can no longer unpack it to my NAS
drive. I am Leaving Sunday for a week at Conception Abbey in Missouri
and will not be back until a week from Saturday when I will have time to
threaten the system with bodily harm and get at least one one method to
work.

Regards
Keith




signature.asc
Description: OpenPGP digital signature

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Marcus,

On 6/10/21 9:29 AM, Marcus wrote:

Am 08.06.21 um 11:16 schrieb Matthias Seidel:

Find the Windows build here:

https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe 



here my results:

http://www.openoffice.org/
http://www.openoffice.org/test.exe
http://www.openoffice.org/test.ods
https://www.openoffice.org/
https://www.openoffice.org/test.exe
https://www.openoffice.org/test.ods

--> Any HTTP or HTTPS links are opened without warning.

smb://www.openoffice.org/
smb://www.openoffice.org/test.exe
smb://www.openoffice.org/test.ods
file://www.openoffice.org/
file://www.openoffice.org/test.exe
file://www.openoffice.org/test.ods

--> Any SMB or FILE links get the warning dialog before opening.

How can I test with UNO links like ".uno:reload"?


The test document I created has a button with a .uno:Reload action.

http://home.apache.org/~cmarcum/hyperlink-tests/

Or make a push button using form controls.
Set Action to Open document/web page
Set URL to .uno:Reload

Best regards,
Carl



Thanks

Marcus




Am 07.06.21 um 18:09 schrieb Marcus:

Am 07.06.21 um 02:12 schrieb Carl Marcum:

Hi Arrigo,

On 6/6/21 3:56 PM, Arrigo Marchiori wrote:

Hello Carl, All,

On Sun, Jun 06, 2021 at 11:50:12AM -0400, Carl Marcum wrote:


Hi Arrigo and All,

On 6/5/21 5:53 PM, Arrigo Marchiori wrote:

Hello Carl, All,

On Sat, Jun 05, 2021 at 03:47:12PM -0400, Carl Marcum wrote:


Hi Arrigo,

On 6/5/21 9:50 AM, Arrigo Marchiori wrote:

Dear Matthias, Czesław, All,

On Sat, Jun 05, 2021 at 12:39:16PM +0200, Matthias Seidel wrote:


Hi Czesław,

Am 05.06.21 um 12:35 schrieb Czesław Wolański:

Hi Matthias, all

A preliminary check in Calc (Windows 7, 64-bit)

(1) in-document links beginning with #
test: button with link to other sheet
result: OK (no security warning)

(2) .uno:XXX links
result: security warning

(3) Links to local files
test: the "Hyperlink" dialog, button "WWW Browser"
result: OK (no security warning)

That's what I expected, since the patches are for file://

.uno: hasn't been addressed yet

@Arrigo: correct me if I am wrong ;-)

You should have just become wrong ;-)

I found out that there are many checks on the URL protocol. I
suggest
that the warning was not checked at the right moment, but too 
soon.


Because we had a report of unexpected _execution_ of malicious
links,
I suggest we leave the safety check on hyperlinks _just before
calling
the OS to execute them_.

The result is that HTTP, HTTPS, but also "uno:" and all other
protocols already understood by AOO are not checked, and no
warnings
will appear. We could argue that their safety must be assured by
the
code handling them, as we accepted to delegate the browser for
Internet links.

The latest commit, just pushed to branch bug128453, moves the 
check

for "safe extensions" (or directory) from the beginning of
hyperlinks'
processing, to just before the execution of the link target by
the OS.
The protocol is not checked any more, because supported protocols
are already filtered out and processed at that point.

This should make all links to non-files work again, and still 
warn

users when they are going to open JAR's, EXE's and other unknown
types.

What do you think about this?

I like your thinking on this.
I'll build this branch on Linux and test using some of the test
documents
and ones I've made to make sure I understand the different cases.
Then I'll report back.

You can find my 64 bit Linux builds here:
https://home.apache.org/~ardovm/openoffice/bug128453/

I tried the "beta" option of the build script... I hope it works.

Thank you for your cooperation!

Best regards,

I've built the bug128453 branch [1] on Linux CentOS 7 and ran the
test suite
that included the hyperlink tests for the dialogs [2].

I put together some test documents here [3].

Very nice, thank you!

[...]

So far everything looks good and I get the warning everywhere I
expect to
with one exception.
The smb://nonexistant.url.com link does not display the warning and
I get
this output:
---
This tool has been deprecated, use 'gio open' instead.
See 'gio help open' for more info.

gio: smb://nonexistant.url.com/: The specified location is not 
mounted

---
Note that I build on CentOS 7 and use --enable-gio and
--disable-gnome-vfs
in configure.

Maybe there is a reason the SMB protocol is treated differently
than the
others when there is only the host section of the url?

I'm not saying this is bad but just different. We can discuss...

Sure.

The smb:// protocol is treated like file://. A proof of this is that
the link to "smb://nonexistant.url.com/evil.jar" shows a warning 
dialog

because the ".jar" extension is not considered safe.

For the same reason, f you create a link to
"smb://nonexistant.url.com/whatever.ods" it will be opened without
warnings.

The link you are discussing points to "smb://nonexistant.url.com/".
The target ends with a backslash, therefore it is considered 

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Keith,

Could you provide a test document?

Or (if you use Windows) make a test with this build:

https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/Full%20Installation/Apache_OpenOffice_4.2.0_Win_x86_install_en-US_56e2535bb8.exe

Regards,

   Matthias

Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
> For some years I've had a Reload button in my Calc document to avoid having 
> to use the File menu. Just updated to 4.1.10 and now I get a message when 
> pressing Reload button: 
>
> This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
>
> Is there a way of switching off this message please?
>
> Thanks.
>
> Regards
> Keith Shelton
>
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Marcus]

Am 08.06.21 um 11:16 schrieb Matthias Seidel:

Find the Windows build here:

https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe


here my results:

http://www.openoffice.org/
http://www.openoffice.org/test.exe
http://www.openoffice.org/test.ods
https://www.openoffice.org/
https://www.openoffice.org/test.exe
https://www.openoffice.org/test.ods

--> Any HTTP or HTTPS links are opened without warning.

smb://www.openoffice.org/
smb://www.openoffice.org/test.exe
smb://www.openoffice.org/test.ods
file://www.openoffice.org/
file://www.openoffice.org/test.exe
file://www.openoffice.org/test.ods

--> Any SMB or FILE links get the warning dialog before opening.

How can I test with UNO links like ".uno:reload"?

Thanks

Marcus




Am 07.06.21 um 18:09 schrieb Marcus:

Am 07.06.21 um 02:12 schrieb Carl Marcum:

Hi Arrigo,

On 6/6/21 3:56 PM, Arrigo Marchiori wrote:

Hello Carl, All,

On Sun, Jun 06, 2021 at 11:50:12AM -0400, Carl Marcum wrote:


Hi Arrigo and All,

On 6/5/21 5:53 PM, Arrigo Marchiori wrote:

Hello Carl, All,

On Sat, Jun 05, 2021 at 03:47:12PM -0400, Carl Marcum wrote:


Hi Arrigo,

On 6/5/21 9:50 AM, Arrigo Marchiori wrote:

Dear Matthias, Czesław, All,

On Sat, Jun 05, 2021 at 12:39:16PM +0200, Matthias Seidel wrote:


Hi Czesław,

Am 05.06.21 um 12:35 schrieb Czesław Wolański:

Hi Matthias, all

A preliminary check in Calc (Windows 7, 64-bit)

(1) in-document links beginning with #
test: button with link to other sheet
result: OK (no security warning)

(2) .uno:XXX links
result: security warning

(3) Links to local files
test: the "Hyperlink" dialog, button "WWW Browser"
result: OK (no security warning)

That's what I expected, since the patches are for file://

.uno: hasn't been addressed yet

@Arrigo: correct me if I am wrong ;-)

You should have just become wrong ;-)

I found out that there are many checks on the URL protocol. I
suggest
that the warning was not checked at the right moment, but too soon.

Because we had a report of unexpected _execution_ of malicious
links,
I suggest we leave the safety check on hyperlinks _just before
calling
the OS to execute them_.

The result is that HTTP, HTTPS, but also "uno:" and all other
protocols already understood by AOO are not checked, and no
warnings
will appear. We could argue that their safety must be assured by
the
code handling them, as we accepted to delegate the browser for
Internet links.

The latest commit, just pushed to branch bug128453, moves the check
for "safe extensions" (or directory) from the beginning of
hyperlinks'
processing, to just before the execution of the link target by
the OS.
The protocol is not checked any more, because supported protocols
are already filtered out and processed at that point.

This should make all links to non-files work again, and still warn
users when they are going to open JAR's, EXE's and other unknown
types.

What do you think about this?

I like your thinking on this.
I'll build this branch on Linux and test using some of the test
documents
and ones I've made to make sure I understand the different cases.
Then I'll report back.

You can find my 64 bit Linux builds here:
https://home.apache.org/~ardovm/openoffice/bug128453/

I tried the "beta" option of the build script... I hope it works.

Thank you for your cooperation!

Best regards,

I've built the bug128453 branch [1] on Linux CentOS 7 and ran the
test suite
that included the hyperlink tests for the dialogs [2].

I put together some test documents here [3].

Very nice, thank you!

[...]

So far everything looks good and I get the warning everywhere I
expect to
with one exception.
The smb://nonexistant.url.com link does not display the warning and
I get
this output:
---
This tool has been deprecated, use 'gio open' instead.
See 'gio help open' for more info.

gio: smb://nonexistant.url.com/: The specified location is not mounted
---
Note that I build on CentOS 7 and use --enable-gio and
--disable-gnome-vfs
in configure.

Maybe there is a reason the SMB protocol is treated differently
than the
others when there is only the host section of the url?

I'm not saying this is bad but just different. We can discuss...

Sure.

The smb:// protocol is treated like file://. A proof of this is that
the link to "smb://nonexistant.url.com/evil.jar" shows a warning dialog
because the ".jar" extension is not considered safe.

For the same reason, f you create a link to
"smb://nonexistant.url.com/whatever.ods" it will be opened without
warnings.

The link you are discussing points to "smb://nonexistant.url.com/".
The target ends with a backslash, therefore it is considered a
directory, and thus safe.

Thanks for pointing this out. I intended it to end without the /.
For some reason AOO adds the trailing / for the smb link no matter
what I try.
But not for the other types.  Even in the automated test since it
just robots the UI.

I've removed the smb link in the test 

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi all,

Find the Windows build here:

https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_6652b2eb2e.exe

Regards,

   Matthias

Am 07.06.21 um 18:09 schrieb Marcus:
> Am 07.06.21 um 02:12 schrieb Carl Marcum:
>> Hi Arrigo,
>>
>> On 6/6/21 3:56 PM, Arrigo Marchiori wrote:
>>> Hello Carl, All,
>>>
>>> On Sun, Jun 06, 2021 at 11:50:12AM -0400, Carl Marcum wrote:
>>>
 Hi Arrigo and All,

 On 6/5/21 5:53 PM, Arrigo Marchiori wrote:
> Hello Carl, All,
>
> On Sat, Jun 05, 2021 at 03:47:12PM -0400, Carl Marcum wrote:
>
>> Hi Arrigo,
>>
>> On 6/5/21 9:50 AM, Arrigo Marchiori wrote:
>>> Dear Matthias, Czesław, All,
>>>
>>> On Sat, Jun 05, 2021 at 12:39:16PM +0200, Matthias Seidel wrote:
>>>
 Hi Czesław,

 Am 05.06.21 um 12:35 schrieb Czesław Wolański:
> Hi Matthias, all
>
> A preliminary check in Calc (Windows 7, 64-bit)
>
> (1) in-document links beginning with #
> test: button with link to other sheet
> result: OK (no security warning)
>
> (2) .uno:XXX links
> result: security warning
>
> (3) Links to local files
> test: the "Hyperlink" dialog, button "WWW Browser"
> result: OK (no security warning)
 That's what I expected, since the patches are for file://

 .uno: hasn't been addressed yet

 @Arrigo: correct me if I am wrong ;-)
>>> You should have just become wrong ;-)
>>>
>>> I found out that there are many checks on the URL protocol. I
>>> suggest
>>> that the warning was not checked at the right moment, but too soon.
>>>
>>> Because we had a report of unexpected _execution_ of malicious
>>> links,
>>> I suggest we leave the safety check on hyperlinks _just before
>>> calling
>>> the OS to execute them_.
>>>
>>> The result is that HTTP, HTTPS, but also "uno:" and all other
>>> protocols already understood by AOO are not checked, and no
>>> warnings
>>> will appear. We could argue that their safety must be assured by
>>> the
>>> code handling them, as we accepted to delegate the browser for
>>> Internet links.
>>>
>>> The latest commit, just pushed to branch bug128453, moves the check
>>> for "safe extensions" (or directory) from the beginning of
>>> hyperlinks'
>>> processing, to just before the execution of the link target by
>>> the OS.
>>> The protocol is not checked any more, because supported protocols
>>> are already filtered out and processed at that point.
>>>
>>> This should make all links to non-files work again, and still warn
>>> users when they are going to open JAR's, EXE's and other unknown
>>> types.
>>>
>>> What do you think about this?
>> I like your thinking on this.
>> I'll build this branch on Linux and test using some of the test
>> documents
>> and ones I've made to make sure I understand the different cases.
>> Then I'll report back.
> You can find my 64 bit Linux builds here:
> https://home.apache.org/~ardovm/openoffice/bug128453/
>
> I tried the "beta" option of the build script... I hope it works.
>
> Thank you for your cooperation!
>
> Best regards,
 I've built the bug128453 branch [1] on Linux CentOS 7 and ran the
 test suite
 that included the hyperlink tests for the dialogs [2].

 I put together some test documents here [3].
>>> Very nice, thank you!
>>>
>>> [...]
 So far everything looks good and I get the warning everywhere I
 expect to
 with one exception.
 The smb://nonexistant.url.com link does not display the warning and
 I get
 this output:
 ---
 This tool has been deprecated, use 'gio open' instead.
 See 'gio help open' for more info.

 gio: smb://nonexistant.url.com/: The specified location is not mounted
 ---
 Note that I build on CentOS 7 and use --enable-gio and
 --disable-gnome-vfs
 in configure.

 Maybe there is a reason the SMB protocol is treated differently
 than the
 others when there is only the host section of the url?

 I'm not saying this is bad but just different. We can discuss...
>>> Sure.
>>>
>>> The smb:// protocol is treated like file://. A proof of this is that
>>> the link to "smb://nonexistant.url.com/evil.jar" shows a warning dialog
>>> because the ".jar" extension is not considered safe.
>>>
>>> For the same reason, f you create a link to
>>> "smb://nonexistant.url.com/whatever.ods" it will be opened without
>>> warnings.
>>>
>>> The link you are discussing points to "smb://nonexistant.url.com/".
>>> The target ends with a backslash, therefore it is considered a
>>> directory, and thus safe.
>> Thanks for pointing this out. I intended it to end without the /.
>> 

Re: Hyperlink Warning Message

[Marcus]

Am 07.06.21 um 02:12 schrieb Carl Marcum:

Hi Arrigo,

On 6/6/21 3:56 PM, Arrigo Marchiori wrote:

Hello Carl, All,

On Sun, Jun 06, 2021 at 11:50:12AM -0400, Carl Marcum wrote:


Hi Arrigo and All,

On 6/5/21 5:53 PM, Arrigo Marchiori wrote:

Hello Carl, All,

On Sat, Jun 05, 2021 at 03:47:12PM -0400, Carl Marcum wrote:


Hi Arrigo,

On 6/5/21 9:50 AM, Arrigo Marchiori wrote:

Dear Matthias, Czesław, All,

On Sat, Jun 05, 2021 at 12:39:16PM +0200, Matthias Seidel wrote:


Hi Czesław,

Am 05.06.21 um 12:35 schrieb Czesław Wolański:

Hi Matthias, all

A preliminary check in Calc (Windows 7, 64-bit)

(1) in-document links beginning with #
test: button with link to other sheet
result: OK (no security warning)

(2) .uno:XXX links
result: security warning

(3) Links to local files
test: the "Hyperlink" dialog, button "WWW Browser"
result: OK (no security warning)

That's what I expected, since the patches are for file://

.uno: hasn't been addressed yet

@Arrigo: correct me if I am wrong ;-)

You should have just become wrong ;-)

I found out that there are many checks on the URL protocol. I suggest
that the warning was not checked at the right moment, but too soon.

Because we had a report of unexpected _execution_ of malicious links,
I suggest we leave the safety check on hyperlinks _just before 
calling

the OS to execute them_.

The result is that HTTP, HTTPS, but also "uno:" and all other
protocols already understood by AOO are not checked, and no warnings
will appear. We could argue that their safety must be assured by the
code handling them, as we accepted to delegate the browser for
Internet links.

The latest commit, just pushed to branch bug128453, moves the check
for "safe extensions" (or directory) from the beginning of 
hyperlinks'
processing, to just before the execution of the link target by the 
OS.

The protocol is not checked any more, because supported protocols
are already filtered out and processed at that point.

This should make all links to non-files work again, and still warn
users when they are going to open JAR's, EXE's and other unknown
types.

What do you think about this?

I like your thinking on this.
I'll build this branch on Linux and test using some of the test 
documents

and ones I've made to make sure I understand the different cases.
Then I'll report back.

You can find my 64 bit Linux builds here:
https://home.apache.org/~ardovm/openoffice/bug128453/

I tried the "beta" option of the build script... I hope it works.

Thank you for your cooperation!

Best regards,
I've built the bug128453 branch [1] on Linux CentOS 7 and ran the 
test suite

that included the hyperlink tests for the dialogs [2].

I put together some test documents here [3].

Very nice, thank you!

[...]
So far everything looks good and I get the warning everywhere I 
expect to

with one exception.
The smb://nonexistant.url.com link does not display the warning and I 
get

this output:
---
This tool has been deprecated, use 'gio open' instead.
See 'gio help open' for more info.

gio: smb://nonexistant.url.com/: The specified location is not mounted
---
Note that I build on CentOS 7 and use --enable-gio and 
--disable-gnome-vfs

in configure.

Maybe there is a reason the SMB protocol is treated differently than the
others when there is only the host section of the url?

I'm not saying this is bad but just different. We can discuss...

Sure.

The smb:// protocol is treated like file://. A proof of this is that
the link to "smb://nonexistant.url.com/evil.jar" shows a warning dialog
because the ".jar" extension is not considered safe.

For the same reason, f you create a link to
"smb://nonexistant.url.com/whatever.ods" it will be opened without
warnings.

The link you are discussing points to "smb://nonexistant.url.com/".
The target ends with a backslash, therefore it is considered a
directory, and thus safe.

Thanks for pointing this out. I intended it to end without the /.
For some reason AOO adds the trailing / for the smb link no matter what 
I try.
But not for the other types.  Even in the automated test since it just 
robots the UI.


I've removed the smb link in the test document and uploaded a new copy.

I'll also disable that specific test in the test suite as well due to 
this behavior.




This is the current logic. It may be worth discussing whether we want
to consider links to directories safe or not.

The warning messages you reported about gio are worth another
discussion: we may need to update the way we "talk to" the OS under
GNOME. But as long as it works on current distributions, I would
refrain from changing it.

I hope that the above makes sense.

Best regards,

So now I'll say everything works as expected.

Thanks again for your work on this!


Yes, thanks a lot for your efforts. :-)

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Arrigo,

On 6/6/21 3:56 PM, Arrigo Marchiori wrote:

Hello Carl, All,

On Sun, Jun 06, 2021 at 11:50:12AM -0400, Carl Marcum wrote:


Hi Arrigo and All,

On 6/5/21 5:53 PM, Arrigo Marchiori wrote:

Hello Carl, All,

On Sat, Jun 05, 2021 at 03:47:12PM -0400, Carl Marcum wrote:


Hi Arrigo,

On 6/5/21 9:50 AM, Arrigo Marchiori wrote:

Dear Matthias, Czesław, All,

On Sat, Jun 05, 2021 at 12:39:16PM +0200, Matthias Seidel wrote:


Hi Czesław,

Am 05.06.21 um 12:35 schrieb Czesław Wolański:

Hi Matthias, all

A preliminary check in Calc (Windows 7, 64-bit)

(1) in-document links beginning with #
test: button with link to other sheet
result: OK (no security warning)

(2) .uno:XXX links
result: security warning

(3) Links to local files
test: the "Hyperlink" dialog, button "WWW Browser"
result: OK (no security warning)

That's what I expected, since the patches are for file://

.uno: hasn't been addressed yet

@Arrigo: correct me if I am wrong ;-)

You should have just become wrong ;-)

I found out that there are many checks on the URL protocol. I suggest
that the warning was not checked at the right moment, but too soon.

Because we had a report of unexpected _execution_ of malicious links,
I suggest we leave the safety check on hyperlinks _just before calling
the OS to execute them_.

The result is that HTTP, HTTPS, but also "uno:" and all other
protocols already understood by AOO are not checked, and no warnings
will appear. We could argue that their safety must be assured by the
code handling them, as we accepted to delegate the browser for
Internet links.

The latest commit, just pushed to branch bug128453, moves the check
for "safe extensions" (or directory) from the beginning of hyperlinks'
processing, to just before the execution of the link target by the OS.
The protocol is not checked any more, because supported protocols
are already filtered out and processed at that point.

This should make all links to non-files work again, and still warn
users when they are going to open JAR's, EXE's and other unknown
types.

What do you think about this?

I like your thinking on this.
I'll build this branch on Linux and test using some of the test documents
and ones I've made to make sure I understand the different cases.
Then I'll report back.

You can find my 64 bit Linux builds here:
https://home.apache.org/~ardovm/openoffice/bug128453/

I tried the "beta" option of the build script... I hope it works.

Thank you for your cooperation!

Best regards,

I've built the bug128453 branch [1] on Linux CentOS 7 and ran the test suite
that included the hyperlink tests for the dialogs [2].

I put together some test documents here [3].

Very nice, thank you!

[...]

So far everything looks good and I get the warning everywhere I expect to
with one exception.
The smb://nonexistant.url.com link does not display the warning and I get
this output:
---
This tool has been deprecated, use 'gio open' instead.
See 'gio help open' for more info.

gio: smb://nonexistant.url.com/: The specified location is not mounted
---
Note that I build on CentOS 7 and use --enable-gio and --disable-gnome-vfs
in configure.

Maybe there is a reason the SMB protocol is treated differently than the
others when there is only the host section of the url?

I'm not saying this is bad but just different. We can discuss...

Sure.

The smb:// protocol is treated like file://. A proof of this is that
the link to "smb://nonexistant.url.com/evil.jar" shows a warning dialog
because the ".jar" extension is not considered safe.

For the same reason, f you create a link to
"smb://nonexistant.url.com/whatever.ods" it will be opened without
warnings.

The link you are discussing points to "smb://nonexistant.url.com/".
The target ends with a backslash, therefore it is considered a
directory, and thus safe.

Thanks for pointing this out. I intended it to end without the /.
For some reason AOO adds the trailing / for the smb link no matter what 
I try.
But not for the other types.  Even in the automated test since it just 
robots the UI.


I've removed the smb link in the test document and uploaded a new copy.

I'll also disable that specific test in the test suite as well due to 
this behavior.




This is the current logic. It may be worth discussing whether we want
to consider links to directories safe or not.

The warning messages you reported about gio are worth another
discussion: we may need to update the way we "talk to" the OS under
GNOME. But as long as it works on current distributions, I would
refrain from changing it.

I hope that the above makes sense.

Best regards,

So now I'll say everything works as expected.

Thanks again for your work on this!

Best regards,
Carl


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Hello Carl, All,

On Sun, Jun 06, 2021 at 11:50:12AM -0400, Carl Marcum wrote:

> Hi Arrigo and All,
> 
> On 6/5/21 5:53 PM, Arrigo Marchiori wrote:
> > Hello Carl, All,
> > 
> > On Sat, Jun 05, 2021 at 03:47:12PM -0400, Carl Marcum wrote:
> > 
> > > Hi Arrigo,
> > > 
> > > On 6/5/21 9:50 AM, Arrigo Marchiori wrote:
> > > > Dear Matthias, Czesław, All,
> > > > 
> > > > On Sat, Jun 05, 2021 at 12:39:16PM +0200, Matthias Seidel wrote:
> > > > 
> > > > > Hi Czesław,
> > > > > 
> > > > > Am 05.06.21 um 12:35 schrieb Czesław Wolański:
> > > > > > Hi Matthias, all
> > > > > > 
> > > > > > A preliminary check in Calc (Windows 7, 64-bit)
> > > > > > 
> > > > > > (1) in-document links beginning with #
> > > > > > test: button with link to other sheet
> > > > > > result: OK (no security warning)
> > > > > > 
> > > > > > (2) .uno:XXX links
> > > > > > result: security warning
> > > > > > 
> > > > > > (3) Links to local files
> > > > > > test: the "Hyperlink" dialog, button "WWW Browser"
> > > > > > result: OK (no security warning)
> > > > > That's what I expected, since the patches are for file://
> > > > > 
> > > > > .uno: hasn't been addressed yet
> > > > > 
> > > > > @Arrigo: correct me if I am wrong ;-)
> > > > You should have just become wrong ;-)
> > > > 
> > > > I found out that there are many checks on the URL protocol. I suggest
> > > > that the warning was not checked at the right moment, but too soon.
> > > > 
> > > > Because we had a report of unexpected _execution_ of malicious links,
> > > > I suggest we leave the safety check on hyperlinks _just before calling
> > > > the OS to execute them_.
> > > > 
> > > > The result is that HTTP, HTTPS, but also "uno:" and all other
> > > > protocols already understood by AOO are not checked, and no warnings
> > > > will appear. We could argue that their safety must be assured by the
> > > > code handling them, as we accepted to delegate the browser for
> > > > Internet links.
> > > > 
> > > > The latest commit, just pushed to branch bug128453, moves the check
> > > > for "safe extensions" (or directory) from the beginning of hyperlinks'
> > > > processing, to just before the execution of the link target by the OS.
> > > > The protocol is not checked any more, because supported protocols
> > > > are already filtered out and processed at that point.
> > > > 
> > > > This should make all links to non-files work again, and still warn
> > > > users when they are going to open JAR's, EXE's and other unknown
> > > > types.
> > > > 
> > > > What do you think about this?
> > > I like your thinking on this.
> > > I'll build this branch on Linux and test using some of the test documents
> > > and ones I've made to make sure I understand the different cases.
> > > Then I'll report back.
> > You can find my 64 bit Linux builds here:
> > https://home.apache.org/~ardovm/openoffice/bug128453/
> > 
> > I tried the "beta" option of the build script... I hope it works.
> > 
> > Thank you for your cooperation!
> > 
> > Best regards,
> 
> I've built the bug128453 branch [1] on Linux CentOS 7 and ran the test suite
> that included the hyperlink tests for the dialogs [2].
> 
> I put together some test documents here [3].

Very nice, thank you!

[...] 
> So far everything looks good and I get the warning everywhere I expect to
> with one exception.
> The smb://nonexistant.url.com link does not display the warning and I get
> this output:
> ---
> This tool has been deprecated, use 'gio open' instead.
> See 'gio help open' for more info.
> 
> gio: smb://nonexistant.url.com/: The specified location is not mounted
> ---
> Note that I build on CentOS 7 and use --enable-gio and --disable-gnome-vfs
> in configure.
> 
> Maybe there is a reason the SMB protocol is treated differently than the
> others when there is only the host section of the url?
> 
> I'm not saying this is bad but just different. We can discuss...

Sure.

The smb:// protocol is treated like file://. A proof of this is that
the link to "smb://nonexistant.url.com/evil.jar" shows a warning dialog
because the ".jar" extension is not considered safe.

For the same reason, f you create a link to
"smb://nonexistant.url.com/whatever.ods" it will be opened without
warnings.

The link you are discussing points to "smb://nonexistant.url.com/".
The target ends with a backslash, therefore it is considered a
directory, and thus safe.

This is the current logic. It may be worth discussing whether we want
to consider links to directories safe or not.

The warning messages you reported about gio are worth another
discussion: we may need to update the way we "talk to" the OS under
GNOME. But as long as it works on current distributions, I would
refrain from changing it.

I hope that the above makes sense.

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Arrigo and All,

On 6/5/21 5:53 PM, Arrigo Marchiori wrote:

Hello Carl, All,

On Sat, Jun 05, 2021 at 03:47:12PM -0400, Carl Marcum wrote:


Hi Arrigo,

On 6/5/21 9:50 AM, Arrigo Marchiori wrote:

Dear Matthias, Czesław, All,

On Sat, Jun 05, 2021 at 12:39:16PM +0200, Matthias Seidel wrote:


Hi Czesław,

Am 05.06.21 um 12:35 schrieb Czesław Wolański:

Hi Matthias, all

A preliminary check in Calc (Windows 7, 64-bit)

(1) in-document links beginning with #
test: button with link to other sheet
result: OK (no security warning)

(2) .uno:XXX links
result: security warning

(3) Links to local files
test: the "Hyperlink" dialog, button "WWW Browser"
result: OK (no security warning)

That's what I expected, since the patches are for file://

.uno: hasn't been addressed yet

@Arrigo: correct me if I am wrong ;-)

You should have just become wrong ;-)

I found out that there are many checks on the URL protocol. I suggest
that the warning was not checked at the right moment, but too soon.

Because we had a report of unexpected _execution_ of malicious links,
I suggest we leave the safety check on hyperlinks _just before calling
the OS to execute them_.

The result is that HTTP, HTTPS, but also "uno:" and all other
protocols already understood by AOO are not checked, and no warnings
will appear. We could argue that their safety must be assured by the
code handling them, as we accepted to delegate the browser for
Internet links.

The latest commit, just pushed to branch bug128453, moves the check
for "safe extensions" (or directory) from the beginning of hyperlinks'
processing, to just before the execution of the link target by the OS.
The protocol is not checked any more, because supported protocols
are already filtered out and processed at that point.

This should make all links to non-files work again, and still warn
users when they are going to open JAR's, EXE's and other unknown
types.

What do you think about this?

I like your thinking on this.
I'll build this branch on Linux and test using some of the test documents
and ones I've made to make sure I understand the different cases.
Then I'll report back.

You can find my 64 bit Linux builds here:
https://home.apache.org/~ardovm/openoffice/bug128453/

I tried the "beta" option of the build script... I hope it works.

Thank you for your cooperation!

Best regards,


I've built the bug128453 branch [1] on Linux CentOS 7 and ran the test 
suite that included the hyperlink tests for the dialogs [2].


I put together some test documents here [3].
hyperlink-test-doc.odt has the same 9 links I have in the test suite 
that threw the warning dialog with 4.1.10. plus there is a section of 
http(s) links that should not display it.


There is a button that uses the .uno:Reload command that was throwing 
the dialog in 4.1.10 that doesn't with this test build.


I've also included a section with file:/// links. 2 for the other file 
hyperlink-test-target.odt and one inter-document link to one the 
sections in the same test doc.


So far everything looks good and I get the warning everywhere I expect 
to with one exception.
The smb://nonexistant.url.com link does not display the warning and I 
get this output:

---
This tool has been deprecated, use 'gio open' instead.
See 'gio help open' for more info.

gio: smb://nonexistant.url.com/: The specified location is not mounted
---
Note that I build on CentOS 7 and use --enable-gio and 
--disable-gnome-vfs in configure.


Maybe there is a reason the SMB protocol is treated differently than the 
others when there is only the host section of the url?


I'm not saying this is bad but just different. We can discuss...

Best regards,
Carl


[1] 
https://github.com/apache/openoffice/commit/6652b2eb2edb94addf9b9f84de155dbbbcb89b02


[2] 
https://github.com/apache/openoffice/blob/trunk/test/testgui/source/fvt/gui/sw/hyperlink/WarningDialog.java


[3] http://home.apache.org/~cmarcum/hyperlink-tests/

Best regards,
Carl


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Peter Kovacs]

On 05.06.21 15:50, Arrigo Marchiori wrote:

Dear Matthias, Czesław, All,

On Sat, Jun 05, 2021 at 12:39:16PM +0200, Matthias Seidel wrote:


Hi Czesław,

Am 05.06.21 um 12:35 schrieb Czesław Wolański:

Hi Matthias, all

A preliminary check in Calc (Windows 7, 64-bit)

(1) in-document links beginning with #
test: button with link to other sheet
result: OK (no security warning)

(2) .uno:XXX links
result: security warning

(3) Links to local files
test: the "Hyperlink" dialog, button "WWW Browser"
result: OK (no security warning)

That's what I expected, since the patches are for file://

.uno: hasn't been addressed yet

@Arrigo: correct me if I am wrong ;-)

You should have just become wrong ;-)

I found out that there are many checks on the URL protocol. I suggest
that the warning was not checked at the right moment, but too soon.

Because we had a report of unexpected _execution_ of malicious links,
I suggest we leave the safety check on hyperlinks _just before calling
the OS to execute them_.

The result is that HTTP, HTTPS, but also "uno:" and all other
protocols already understood by AOO are not checked, and no warnings
will appear. We could argue that their safety must be assured by the
code handling them, as we accepted to delegate the browser for
Internet links.

The latest commit, just pushed to branch bug128453, moves the check
for "safe extensions" (or directory) from the beginning of hyperlinks'
processing, to just before the execution of the link target by the OS.
The protocol is not checked any more, because supported protocols
are already filtered out and processed at that point.

This should make all links to non-files work again, and still warn
users when they are going to open JAR's, EXE's and other unknown
types.

What do you think about this?


I like this a lot. It seems that you have found the solution. The main 
pain point is that the user is warned on possible code execution.


Thank you for your relentless time to look into this issue.


All the best

Peter

--
This is the Way! http://www.apache.org/theapacheway/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Hello Carl, All,

On Sat, Jun 05, 2021 at 03:47:12PM -0400, Carl Marcum wrote:

> Hi Arrigo,
> 
> On 6/5/21 9:50 AM, Arrigo Marchiori wrote:
> > Dear Matthias, Czesław, All,
> > 
> > On Sat, Jun 05, 2021 at 12:39:16PM +0200, Matthias Seidel wrote:
> > 
> > > Hi Czesław,
> > > 
> > > Am 05.06.21 um 12:35 schrieb Czesław Wolański:
> > > > Hi Matthias, all
> > > > 
> > > > A preliminary check in Calc (Windows 7, 64-bit)
> > > > 
> > > > (1) in-document links beginning with #
> > > > test: button with link to other sheet
> > > > result: OK (no security warning)
> > > > 
> > > > (2) .uno:XXX links
> > > > result: security warning
> > > > 
> > > > (3) Links to local files
> > > > test: the "Hyperlink" dialog, button "WWW Browser"
> > > > result: OK (no security warning)
> > > That's what I expected, since the patches are for file://
> > > 
> > > .uno: hasn't been addressed yet
> > > 
> > > @Arrigo: correct me if I am wrong ;-)
> > You should have just become wrong ;-)
> > 
> > I found out that there are many checks on the URL protocol. I suggest
> > that the warning was not checked at the right moment, but too soon.
> > 
> > Because we had a report of unexpected _execution_ of malicious links,
> > I suggest we leave the safety check on hyperlinks _just before calling
> > the OS to execute them_.
> > 
> > The result is that HTTP, HTTPS, but also "uno:" and all other
> > protocols already understood by AOO are not checked, and no warnings
> > will appear. We could argue that their safety must be assured by the
> > code handling them, as we accepted to delegate the browser for
> > Internet links.
> > 
> > The latest commit, just pushed to branch bug128453, moves the check
> > for "safe extensions" (or directory) from the beginning of hyperlinks'
> > processing, to just before the execution of the link target by the OS.
> > The protocol is not checked any more, because supported protocols
> > are already filtered out and processed at that point.
> > 
> > This should make all links to non-files work again, and still warn
> > users when they are going to open JAR's, EXE's and other unknown
> > types.
> > 
> > What do you think about this?
> I like your thinking on this.
> I'll build this branch on Linux and test using some of the test documents
> and ones I've made to make sure I understand the different cases.
> Then I'll report back.

You can find my 64 bit Linux builds here:
https://home.apache.org/~ardovm/openoffice/bug128453/

I tried the "beta" option of the build script... I hope it works.

Thank you for your cooperation!

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Arrigo,

On 6/5/21 9:50 AM, Arrigo Marchiori wrote:

Dear Matthias, Czesław, All,

On Sat, Jun 05, 2021 at 12:39:16PM +0200, Matthias Seidel wrote:


Hi Czesław,

Am 05.06.21 um 12:35 schrieb Czesław Wolański:

Hi Matthias, all

A preliminary check in Calc (Windows 7, 64-bit)

(1) in-document links beginning with #
test: button with link to other sheet
result: OK (no security warning)

(2) .uno:XXX links
result: security warning

(3) Links to local files
test: the "Hyperlink" dialog, button "WWW Browser"
result: OK (no security warning)

That's what I expected, since the patches are for file://

.uno: hasn't been addressed yet

@Arrigo: correct me if I am wrong ;-)

You should have just become wrong ;-)

I found out that there are many checks on the URL protocol. I suggest
that the warning was not checked at the right moment, but too soon.

Because we had a report of unexpected _execution_ of malicious links,
I suggest we leave the safety check on hyperlinks _just before calling
the OS to execute them_.

The result is that HTTP, HTTPS, but also "uno:" and all other
protocols already understood by AOO are not checked, and no warnings
will appear. We could argue that their safety must be assured by the
code handling them, as we accepted to delegate the browser for
Internet links.

The latest commit, just pushed to branch bug128453, moves the check
for "safe extensions" (or directory) from the beginning of hyperlinks'
processing, to just before the execution of the link target by the OS.
The protocol is not checked any more, because supported protocols
are already filtered out and processed at that point.

This should make all links to non-files work again, and still warn
users when they are going to open JAR's, EXE's and other unknown
types.

What do you think about this?

I like your thinking on this.
I'll build this branch on Linux and test using some of the test 
documents and ones I've made to make sure I understand the different cases.

Then I'll report back.

Thanks again for your work on this!

Best regards,
Carl



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Dear Matthias, Czesław, All,

On Sat, Jun 05, 2021 at 12:39:16PM +0200, Matthias Seidel wrote:

> Hi Czesław,
> 
> Am 05.06.21 um 12:35 schrieb Czesław Wolański:
> > Hi Matthias, all
> >
> > A preliminary check in Calc (Windows 7, 64-bit)
> >
> > (1) in-document links beginning with #
> > test: button with link to other sheet
> > result: OK (no security warning)
> >
> > (2) .uno:XXX links
> > result: security warning
> >
> > (3) Links to local files
> > test: the "Hyperlink" dialog, button "WWW Browser"
> > result: OK (no security warning)
> 
> That's what I expected, since the patches are for file://
> 
> .uno: hasn't been addressed yet
> 
> @Arrigo: correct me if I am wrong ;-)

You should have just become wrong ;-)

I found out that there are many checks on the URL protocol. I suggest
that the warning was not checked at the right moment, but too soon.

Because we had a report of unexpected _execution_ of malicious links,
I suggest we leave the safety check on hyperlinks _just before calling
the OS to execute them_.

The result is that HTTP, HTTPS, but also "uno:" and all other
protocols already understood by AOO are not checked, and no warnings
will appear. We could argue that their safety must be assured by the
code handling them, as we accepted to delegate the browser for
Internet links.

The latest commit, just pushed to branch bug128453, moves the check
for "safe extensions" (or directory) from the beginning of hyperlinks'
processing, to just before the execution of the link target by the OS.
The protocol is not checked any more, because supported protocols
are already filtered out and processed at that point.

This should make all links to non-files work again, and still warn
users when they are going to open JAR's, EXE's and other unknown
types.

What do you think about this?
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Czesław Wolański]

Hi Matthias,

> That's what I expected, since the patches are for file://
>
> .uno: hasn't been addressed yet

Yes I know.

"The impossible we can do right now. Miracles take a little longer."   ;‑)

Regards,
Czesław

сб, 5 июн. 2021 г. в 12:39, Matthias Seidel :

> Hi Czesław,
>
> Am 05.06.21 um 12:35 schrieb Czesław Wolański:
> > Hi Matthias, all
> >
> > A preliminary check in Calc (Windows 7, 64-bit)
> >
> > (1) in-document links beginning with #
> > test: button with link to other sheet
> > result: OK (no security warning)
> >
> > (2) .uno:XXX links
> > result: security warning
> >
> > (3) Links to local files
> > test: the "Hyperlink" dialog, button "WWW Browser"
> > result: OK (no security warning)
>
> That's what I expected, since the patches are for file://
>
> .uno: hasn't been addressed yet
>
> @Arrigo: correct me if I am wrong ;-)
>
> Regards,
>
>Matthias
>
> >
> >
> > Regards,
> > Czesław
> >
> > сб, 5 июн. 2021 г. в 11:20, Matthias Seidel  >:
> >
> >> Hi all,
> >>
> >> Am 04.06.21 um 19:20 schrieb Matthias Seidel:
> >>> Hi Arrigo,
> >>>
> >>> Am 01.06.21 um 21:57 schrieb Arrigo Marchiori:
> > We are grabbing an INetURLObject here:
> >
> >>
> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#929
> > The code after here
> >>
> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#1040
> >> may be helpful.
>  I do not seem to be able to open your links, sorry...
> >>> I have no problem opening these links...
>  Please see branch bug128453, just pushed.
> >>> I just started a Windows Test Build on that branch.
> >> Here it is:
> >>
> >>
> >>
> https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_af31ee45ce.exe
> >>
> >> Regards,
> >>
> >>Matthias
> >>
> >>> Regards,
> >>>
> >>>Matthias
> >>>
>  I will look for older CVE's in the next days.
> 
>  I hope this helps.
> 
>  Best regards,
> >>
>
>

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Czesław,

Am 05.06.21 um 12:35 schrieb Czesław Wolański:
> Hi Matthias, all
>
> A preliminary check in Calc (Windows 7, 64-bit)
>
> (1) in-document links beginning with #
> test: button with link to other sheet
> result: OK (no security warning)
>
> (2) .uno:XXX links
> result: security warning
>
> (3) Links to local files
> test: the "Hyperlink" dialog, button "WWW Browser"
> result: OK (no security warning)

That's what I expected, since the patches are for file://

.uno: hasn't been addressed yet

@Arrigo: correct me if I am wrong ;-)

Regards,

   Matthias

>
>
> Regards,
> Czesław
>
> сб, 5 июн. 2021 г. в 11:20, Matthias Seidel :
>
>> Hi all,
>>
>> Am 04.06.21 um 19:20 schrieb Matthias Seidel:
>>> Hi Arrigo,
>>>
>>> Am 01.06.21 um 21:57 schrieb Arrigo Marchiori:
> We are grabbing an INetURLObject here:
>
>> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#929
> The code after here
>> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#1040
>> may be helpful.
 I do not seem to be able to open your links, sorry...
>>> I have no problem opening these links...
 Please see branch bug128453, just pushed.
>>> I just started a Windows Test Build on that branch.
>> Here it is:
>>
>>
>> https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_af31ee45ce.exe
>>
>> Regards,
>>
>>Matthias
>>
>>> Regards,
>>>
>>>Matthias
>>>
 I will look for older CVE's in the next days.

 I hope this helps.

 Best regards,
>>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Czesław Wolański]

Hi Matthias, all

A preliminary check in Calc (Windows 7, 64-bit)

(1) in-document links beginning with #
test: button with link to other sheet
result: OK (no security warning)

(2) .uno:XXX links
result: security warning

(3) Links to local files
test: the "Hyperlink" dialog, button "WWW Browser"
result: OK (no security warning)


Regards,
Czesław

сб, 5 июн. 2021 г. в 11:20, Matthias Seidel :

> Hi all,
>
> Am 04.06.21 um 19:20 schrieb Matthias Seidel:
> > Hi Arrigo,
> >
> > Am 01.06.21 um 21:57 schrieb Arrigo Marchiori:
> >>> We are grabbing an INetURLObject here:
> >>>
> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#929
> >>>
> >>> The code after here
> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#1040
> may be helpful.
> >> I do not seem to be able to open your links, sorry...
> > I have no problem opening these links...
> >> Please see branch bug128453, just pushed.
> > I just started a Windows Test Build on that branch.
>
> Here it is:
>
>
> https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_af31ee45ce.exe
>
> Regards,
>
>Matthias
>
> >
> > Regards,
> >
> >Matthias
> >
> >> I will look for older CVE's in the next days.
> >>
> >> I hope this helps.
> >>
> >> Best regards,
>
>

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi all,

Am 04.06.21 um 19:20 schrieb Matthias Seidel:
> Hi Arrigo,
>
> Am 01.06.21 um 21:57 schrieb Arrigo Marchiori:
>>> We are grabbing an INetURLObject here:
>>> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#929
>>>
>>> The code after here 
>>> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#1040
>>>  may be helpful.
>> I do not seem to be able to open your links, sorry...
> I have no problem opening these links...
>> Please see branch bug128453, just pushed.
> I just started a Windows Test Build on that branch.

Here it is:

https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/Full%20Installation/Apache_OpenOffice_4.1.11_Win_x86_install_en-US_af31ee45ce.exe

Regards,

   Matthias

>
> Regards,
>
>    Matthias
>
>> I will look for older CVE's in the next days.
>>
>> I hope this helps.
>>
>> Best regards,



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Hello All,

On Wed, Jun 02, 2021 at 01:00:08PM -0700, Dave Fisher wrote:

> > On Jun 2, 2021, at 11:58 AM, Marcus  wrote:
> > 
> > Am 02.06.21 um 00:07 schrieb Peter Kovacs:
> >> On 01.06.21 21:57, Arrigo Marchiori wrote:
> > I would not go for file://. Can we go for a pattern derivated from 
> > file://path/document.ods#anchor ?
> >>> I am not sure I understand your question, Peter.
> >>> 
> >> I am suggesting not to trust file:// in general, but the anchored URL, 
> > 
> > yes, the securty report is talking about nin-http(s) links, And "ile" is 
> > not http. There we have to treat this as insecure.
> > 
> >> maybe file://*#anchor if you like.
> >> But maybe I got this URL wrong.
> > 
> > Hm, I don't see how an anchor makes the document more secure. ;-)
> 
> We need to know if the file:// is already open.

We might be able to know whether the file is already open, if it is an
AOO document.

But what if the file is a JPG image? Or a MP3 audio? Should it not be
considered safe as well? And for what I know, AOO cannot open images
or MP3's as documents.

Judging on the file extension seems to me the best way to follow, at
least for the file:/// protocol and any other protocols that rely on
XSystemShellExecute::execute().

I hope this makes sense.
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Arrigo,

Am 01.06.21 um 21:57 schrieb Arrigo Marchiori:
>> We are grabbing an INetURLObject here:
>> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#929
>>
>> The code after here 
>> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#1040
>>  may be helpful.
> I do not seem to be able to open your links, sorry...
I have no problem opening these links...
> Please see branch bug128453, just pushed.

I just started a Windows Test Build on that branch.

Regards,

   Matthias

>
> I will look for older CVE's in the next days.
>
> I hope this helps.
>
> Best regards,



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Dave Fisher]

> On Jun 2, 2021, at 11:58 AM, Marcus  wrote:
> 
> Am 02.06.21 um 00:07 schrieb Peter Kovacs:
>> On 01.06.21 21:57, Arrigo Marchiori wrote:
> I would not go for file://. Can we go for a pattern derivated from 
> file://path/document.ods#anchor ?
>>> I am not sure I understand your question, Peter.
>>> 
>> I am suggesting not to trust file:// in general, but the anchored URL, 
> 
> yes, the securty report is talking about nin-http(s) links, And "ile" is not 
> http. There we have to treat this as insecure.
> 
>> maybe file://*#anchor if you like.
>> But maybe I got this URL wrong.
> 
> Hm, I don't see how an anchor makes the document more secure. ;-)

We need to know if the file:// is already open.


> 
> Marcus
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Marcus]

Am 02.06.21 um 00:07 schrieb Peter Kovacs:


On 01.06.21 21:57, Arrigo Marchiori wrote:
I would not go for file://. Can we go for a pattern derivated from 
file://path/document.ods#anchor ?

I am not sure I understand your question, Peter.

I am suggesting not to trust file:// in general, but the anchored URL, 


yes, the securty report is talking about nin-http(s) links, And "ile" is 
not http. There we have to treat this as insecure.



maybe file://*#anchor if you like.
But maybe I got this URL wrong.


Hm, I don't see how an anchor makes the document more secure. ;-)

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Peter Kovacs]

On 01.06.21 21:57, Arrigo Marchiori wrote:

I would not go for file://. Can we go for a pattern derivated from 
file://path/document.ods#anchor ?

I am not sure I understand your question, Peter.

I am suggesting not to trust file:// in general, but the anchored URL, 
maybe file://*#anchor if you like.


But maybe I got this URL wrong.

--
This is the Way! http://www.apache.org/theapacheway/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Dear All,

I'll attempt a multi-level reply here :-)

On Sat, May 29, 2021 at 12:26:52PM -0700, Dave Fisher wrote:

> > On May 28, 2021, at 3:01 PM, Carl Marcum  wrote:
> > 
> > Hi All,
> > 
> > On 5/28/21 4:46 PM, Peter Kovacs wrote:
> >> 
> >> On 28.05.21 22:04, Arrigo Marchiori wrote:
> >>> Hello all,
> >>> 
> >>> replying to an older message in this thread.
> >>> 
> >>> On Thu, May 13, 2021 at 07:23:16PM -0400, Carl Marcum wrote:
> >>> 
> >>> [...]
>  Hopefully we can collect the exceptions in the BZ issue noted in this 
>  thread
>  and then agree on the direction.
>  
>  The few I see so far are:
>  1. in-document links beginning with #.
>  2. .uno:XXX links
>  3. Links to local files.
>  
>  I think all 3 are candidates but that's just me.
> >>> I have bad news about number 1. Apparently, when the link is indicated
> >>> as "#anchor", it is transformed into "file://path/document.ods#anchor"
> >>> and then passed to SfxApplication::OpenDocExec_Impl()
> >>> 
> >>> This means that if we want to have warning-less links to the same
> >>> document, then we may have to consider the file:// protocol possibly
> >>> safe. We should then rely on extensions.
> >>> 
> >>> Suprisingly, the OpenDocument extensions do not seem to be included in
> >>> the standard list of safe extensions. Such list should be in
> >>> main/officecfg/registry/data/org/openoffice/Office/Security.xcu -- I
> >>> cannot recall who brought this to my attention and therefore I am
> >>> unable to credit him/her, I am sorry.
> >>> 
> >>> Does anyone see any possible security issues in considering the
> >>> file:// protocol safe and deciding on the target file's extension
> >>> whether to show a warning or not?
> >> 
> >> I would not go for file://. Can we go for a pattern derivated from 
> >> file://path/document.ods#anchor ?

I am not sure I understand your question, Peter.

> >> We had CVEs in the past working with file links, based odf definition and 
> >> UNO. Maybe you can try the test files from those CVEs.

Ok. I will look for them.

> I think that we should evaluate which protocols are “safe”:
> The full list is here:
> http://opengrok.openoffice.org/xref/aoo4110/main/tools/inc/tools/urlobj.hxx?r=b1cdbd2c#104

Yes Dave, I believe that this is an important question.

> There is this large source file that seems to encode all things to do with a 
> url:
> 
> http://opengrok.openoffice.org/xref/aoo4110/main/tools/source/fsys/urlobj.cxx?r=b1cdbd2c#2080
> main/tools/source/fsys/urlobj.cxx has a getPrefix method which returns:
> http://opengrok.openoffice.org/xref/aoo4110/main/tools/source/fsys/urlobj.cxx?r=b1cdbd2c#349
> 
> 348  
> //
> 349  struct INetURLObject::PrefixInfo
> 350  {
> 351   enum Kind { OFFICIAL, INTERNAL, EXTERNAL, ALIAS }; // order is 
> important!
> 352  
> 353   sal_Char const * m_pPrefix;
> 354   sal_Char const * m_pTranslatedPrefix;
> 355   INetProtocol m_eScheme;
> 356   Kind m_eKind;
> 357  };
> 
> I wonder if Kind is helpful for what should be trusted?

It seems to me, that Kind is used to distinguish between ``official''
prefixes, like "http", that anyone should know, from other prefixes,
specific to AOO.

> We are grabbing an INetURLObject here:
> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#929
> 
> The code after here 
> http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#1040
>  may be helpful.

I do not seem to be able to open your links, sorry...

Now to Carl:

> > I think the file protocol as a hyperlink was considered safe by
> > the office right up until this fix.

Yes, there were no checks. We (re-)enabled them in AOO 4.1.10.

> > It seems the uno and file protocols were caught up in the fix and are the 
> > primary ones causing the users problems.

Correct.

> > I don't believe either of these were the subject of the CVE that was fixed 
> > so I don't think we're harming that one.

Well, the title of the latest CVE was about "non-http(s) schemes". So
it did include file:// links.  But let's remember that there were no
checks on the target file's extension!

> > I would think we could allow these at least for a test build while also 
> > going back and verify the previous CVE's didn't get opened up.

Please see branch bug128453, just pushed.

I will look for older CVE's in the next days.

I hope this helps.

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Dave Fisher]

> On May 28, 2021, at 3:01 PM, Carl Marcum  wrote:
> 
> Hi All,
> 
> On 5/28/21 4:46 PM, Peter Kovacs wrote:
>> 
>> On 28.05.21 22:04, Arrigo Marchiori wrote:
>>> Hello all,
>>> 
>>> replying to an older message in this thread.
>>> 
>>> On Thu, May 13, 2021 at 07:23:16PM -0400, Carl Marcum wrote:
>>> 
>>> [...]
 Hopefully we can collect the exceptions in the BZ issue noted in this 
 thread
 and then agree on the direction.
 
 The few I see so far are:
 1. in-document links beginning with #.
 2. .uno:XXX links
 3. Links to local files.
 
 I think all 3 are candidates but that's just me.
>>> I have bad news about number 1. Apparently, when the link is indicated
>>> as "#anchor", it is transformed into "file://path/document.ods#anchor"
>>> and then passed to SfxApplication::OpenDocExec_Impl()
>>> 
>>> This means that if we want to have warning-less links to the same
>>> document, then we may have to consider the file:// protocol possibly
>>> safe. We should then rely on extensions.
>>> 
>>> Suprisingly, the OpenDocument extensions do not seem to be included in
>>> the standard list of safe extensions. Such list should be in
>>> main/officecfg/registry/data/org/openoffice/Office/Security.xcu -- I
>>> cannot recall who brought this to my attention and therefore I am
>>> unable to credit him/her, I am sorry.
>>> 
>>> Does anyone see any possible security issues in considering the
>>> file:// protocol safe and deciding on the target file's extension
>>> whether to show a warning or not?
>> 
>> I would not go for file://. Can we go for a pattern derivated from 
>> file://path/document.ods#anchor ?
>> 
>> 
>> We had CVEs in the past working with file links, based odf definition and 
>> UNO. Maybe you can try the test files from those CVEs.
>> 

I think that we should evaluate which protocols are “safe”:
The full list is here:
http://opengrok.openoffice.org/xref/aoo4110/main/tools/inc/tools/urlobj.hxx?r=b1cdbd2c#104

There is this large source file that seems to encode all things to do with a 
url:

http://opengrok.openoffice.org/xref/aoo4110/main/tools/source/fsys/urlobj.cxx?r=b1cdbd2c#2080
main/tools/source/fsys/urlobj.cxx has a getPrefix method which returns:
http://opengrok.openoffice.org/xref/aoo4110/main/tools/source/fsys/urlobj.cxx?r=b1cdbd2c#349

348  
//
349  struct INetURLObject::PrefixInfo
350  {
351 enum Kind { OFFICIAL, INTERNAL, EXTERNAL, ALIAS }; // order is 
important!
352  
353 sal_Char const * m_pPrefix;
354 sal_Char const * m_pTranslatedPrefix;
355 INetProtocol m_eScheme;
356 Kind m_eKind;
357  };

I wonder if Kind is helpful for what should be trusted?

We are grabbing an INetURLObject here:
http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#929

The code after here 
http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#1040
 may be helpful.

> 
> I think the file protocol as a hyperlink was considered safe by the office 
> right up until this fix.
> 
> It seems the uno and file protocols were caught up in the fix and are the 
> primary ones causing the users problems.
> I don't believe either of these were the subject of the CVE that was fixed so 
> I don't think we're harming that one.
> 
> I would think we could allow these at least for a test build while also going 
> back and verify the previous CVE's didn't get opened up.
> 
> 
> Just my thoughts.
> Carl
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Dave Fisher]

> On May 28, 2021, at 1:04 PM, Arrigo Marchiori  wrote:
> 
> Hello all,
> 
> replying to an older message in this thread.
> 
> On Thu, May 13, 2021 at 07:23:16PM -0400, Carl Marcum wrote:
> 
> [...]
>> Hopefully we can collect the exceptions in the BZ issue noted in this thread
>> and then agree on the direction.
>> 
>> The few I see so far are:
>> 1. in-document links beginning with #.
>> 2. .uno:XXX links
>> 3. Links to local files.
>> 
>> I think all 3 are candidates but that's just me.
> 
> I have bad news about number 1. Apparently, when the link is indicated
> as "#anchor", it is transformed into "file://path/document.ods#anchor"
> and then passed to SfxApplication::OpenDocExec_Impl()

Is it possible to check to see if "file://path/document.ods” is already open?

> 
> This means that if we want to have warning-less links to the same
> document, then we may have to consider the file:// protocol possibly
> safe. We should then rely on extensions.
> 
> Suprisingly, the OpenDocument extensions do not seem to be included in
> the standard list of safe extensions. Such list should be in
> main/officecfg/registry/data/org/openoffice/Office/Security.xcu -- I
> cannot recall who brought this to my attention and therefore I am
> unable to credit him/her, I am sorry.

I think it was Carl. Updating the Security.xcu file to include all trusted 
extensions make sense regardless of how we choose to handle hyperlinks.

Regards,
Dave

> 
> Does anyone see any possible security issues in considering the
> file:// protocol safe and deciding on the target file's extension
> whether to show a warning or not?
> 
> Best regards,
> -- 
> Arrigo
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Carl Marcum]

Hi All,

On 5/28/21 4:46 PM, Peter Kovacs wrote:


On 28.05.21 22:04, Arrigo Marchiori wrote:

Hello all,

replying to an older message in this thread.

On Thu, May 13, 2021 at 07:23:16PM -0400, Carl Marcum wrote:

[...]
Hopefully we can collect the exceptions in the BZ issue noted in 
this thread

and then agree on the direction.

The few I see so far are:
1. in-document links beginning with #.
2. .uno:XXX links
3. Links to local files.

I think all 3 are candidates but that's just me.

I have bad news about number 1. Apparently, when the link is indicated
as "#anchor", it is transformed into "file://path/document.ods#anchor"
and then passed to SfxApplication::OpenDocExec_Impl()

This means that if we want to have warning-less links to the same
document, then we may have to consider the file:// protocol possibly
safe. We should then rely on extensions.

Suprisingly, the OpenDocument extensions do not seem to be included in
the standard list of safe extensions. Such list should be in
main/officecfg/registry/data/org/openoffice/Office/Security.xcu -- I
cannot recall who brought this to my attention and therefore I am
unable to credit him/her, I am sorry.

Does anyone see any possible security issues in considering the
file:// protocol safe and deciding on the target file's extension
whether to show a warning or not?


I would not go for file://. Can we go for a pattern derivated from 
file://path/document.ods#anchor ?



We had CVEs in the past working with file links, based odf definition 
and UNO. Maybe you can try the test files from those CVEs.




I think the file protocol as a hyperlink was considered safe by the 
office right up until this fix.


It seems the uno and file protocols were caught up in the fix and are 
the primary ones causing the users problems.
I don't believe either of these were the subject of the CVE that was 
fixed so I don't think we're harming that one.


I would think we could allow these at least for a test build while also 
going back and verify the previous CVE's didn't get opened up.



Just my thoughts.
Carl

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Peter Kovacs]

On 28.05.21 22:04, Arrigo Marchiori wrote:

Hello all,

replying to an older message in this thread.

On Thu, May 13, 2021 at 07:23:16PM -0400, Carl Marcum wrote:

[...]

Hopefully we can collect the exceptions in the BZ issue noted in this thread
and then agree on the direction.

The few I see so far are:
1. in-document links beginning with #.
2. .uno:XXX links
3. Links to local files.

I think all 3 are candidates but that's just me.

I have bad news about number 1. Apparently, when the link is indicated
as "#anchor", it is transformed into "file://path/document.ods#anchor"
and then passed to SfxApplication::OpenDocExec_Impl()

This means that if we want to have warning-less links to the same
document, then we may have to consider the file:// protocol possibly
safe. We should then rely on extensions.

Suprisingly, the OpenDocument extensions do not seem to be included in
the standard list of safe extensions. Such list should be in
main/officecfg/registry/data/org/openoffice/Office/Security.xcu -- I
cannot recall who brought this to my attention and therefore I am
unable to credit him/her, I am sorry.

Does anyone see any possible security issues in considering the
file:// protocol safe and deciding on the target file's extension
whether to show a warning or not?


I would not go for file://. Can we go for a pattern derivated from 
file://path/document.ods#anchor ?



We had CVEs in the past working with file links, based odf definition 
and UNO. Maybe you can try the test files from those CVEs.


--
This is the Way! http://www.apache.org/theapacheway/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Hello all,

replying to an older message in this thread.

On Thu, May 13, 2021 at 07:23:16PM -0400, Carl Marcum wrote:

[...]
> Hopefully we can collect the exceptions in the BZ issue noted in this thread
> and then agree on the direction.
> 
> The few I see so far are:
> 1. in-document links beginning with #.
> 2. .uno:XXX links
> 3. Links to local files.
> 
> I think all 3 are candidates but that's just me.

I have bad news about number 1. Apparently, when the link is indicated
as "#anchor", it is transformed into "file://path/document.ods#anchor"
and then passed to SfxApplication::OpenDocExec_Impl()

This means that if we want to have warning-less links to the same
document, then we may have to consider the file:// protocol possibly
safe. We should then rely on extensions.

Suprisingly, the OpenDocument extensions do not seem to be included in
the standard list of safe extensions. Such list should be in
main/officecfg/registry/data/org/openoffice/Office/Security.xcu -- I
cannot recall who brought this to my attention and therefore I am
unable to credit him/her, I am sorry.

Does anyone see any possible security issues in considering the
file:// protocol safe and deciding on the target file's extension
whether to show a warning or not?

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Jim,

Am 14.05.21 um 18:56 schrieb Jim Jagielski:
>> On May 14, 2021, at 1:27 AM, Arrigo Marchiori  
>> wrote:
>>
>>
>> I agree, but how many 4.1.X versions do we want to publish before 4.2.0?
>> Now that we support two digits, please let us not point to 4.1.99 ! ;-)
>>
> FWIW, I tend to agree. We fixed the bug. Maybe its not the best solution, but 
> I don't see why we should continue to "focus" on 4.1.X at the expense of 
> 4.2.X.

We already made some progress on the Release Blockers for 4.2.0.
But the remaining ones are untouched for long time.

What about a 4.2.0-Dev3? We already planned it when 4.1.10 got urgent...

Regards,

   Matthias

>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Jim Jagielski]

> On May 14, 2021, at 1:27 AM, Arrigo Marchiori  wrote:
> 
> 
> I agree, but how many 4.1.X versions do we want to publish before 4.2.0?
> Now that we support two digits, please let us not point to 4.1.99 ! ;-)
> 

FWIW, I tend to agree. We fixed the bug. Maybe its not the best solution, but I 
don't see why we should continue to "focus" on 4.1.X at the expense of 4.2.X.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Marcus]

Am 14.05.21 um 10:19 schrieb Matthias Seidel:

Hi Arrigo,

Am 14.05.21 um 07:27 schrieb Arrigo Marchiori:

Hello Carl, all,

On Thu, May 13, 2021 at 07:23:16PM -0400, Carl Marcum wrote:

[...]


Hopefully we can collect the exceptions in the BZ issue noted in this thread
and then agree on the direction.

The few I see so far are:
1. in-document links beginning with #.
2. .uno:XXX links
3. Links to local files.

I think all 3 are candidates but that's just me.

@Arrigo, were you planning on a PR for AOO41X ?

If not, I can try at least some of it but again I'm not really a C++ guy yet
:)

I suggest we make up our minds on the intended solution first, and
then start coding it. We have seen some interesting proposals, some of
which were quite complex (adding configuration settings, dialogs etc).

The three categories listed above would be candidates for
whitelisting, and this would be the quickest fix. But someone fluent
in UNO should first ensure all of us that no.2 is not going to reopen
any other backdoors!

Maybe this topic is worth a discussion with vote, the Apache way? So
we get our roadmap fixed.


There is also the suggestion (Dave's maybe?) that we add the 3
security levels (that are already in the code) for links to the UI
settings and let the user lock it down or open it up from where it is
now.

Yes, I was referring to this and to Peter's ideas.


Yes, but that will only work for trunk/AOO42X since we need to update
the translations too.

I agree, but how many 4.1.X versions do we want to publish before 4.2.0?
Now that we support two digits, please let us not point to 4.1.99 ! ;-)


As "soon" as all Release Blocker are fixed we can release 4.2.0 ;-)


yes, the goal is easy but to reach it that is the challenge.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Marcus]

Am 14.05.21 um 07:27 schrieb Arrigo Marchiori:

On Thu, May 13, 2021 at 07:23:16PM -0400, Carl Marcum wrote:

[...]

I suggest we make up our minds on the intended solution first, and
then start coding it. We have seen some interesting proposals, some of
which were quite complex (adding configuration settings, dialogs etc).


+1

Otherwise we may need more time with improving the fix again and again.

A little Confluence page could be really helpful to collect the possible 
ways and with a column to express our all favorite way.


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Arrigo,

Am 14.05.21 um 07:27 schrieb Arrigo Marchiori:
> Hello Carl, all,
>
> On Thu, May 13, 2021 at 07:23:16PM -0400, Carl Marcum wrote:
>
> [...]
>
>> Hopefully we can collect the exceptions in the BZ issue noted in this thread
>> and then agree on the direction.
>>
>> The few I see so far are:
>> 1. in-document links beginning with #.
>> 2. .uno:XXX links
>> 3. Links to local files.
>>
>> I think all 3 are candidates but that's just me.
>>
>> @Arrigo, were you planning on a PR for AOO41X ?
>>
>> If not, I can try at least some of it but again I'm not really a C++ guy yet
>> :)
> I suggest we make up our minds on the intended solution first, and
> then start coding it. We have seen some interesting proposals, some of
> which were quite complex (adding configuration settings, dialogs etc).
>
> The three categories listed above would be candidates for
> whitelisting, and this would be the quickest fix. But someone fluent
> in UNO should first ensure all of us that no.2 is not going to reopen
> any other backdoors!
>
> Maybe this topic is worth a discussion with vote, the Apache way? So
> we get our roadmap fixed.
>
 There is also the suggestion (Dave's maybe?) that we add the 3
 security levels (that are already in the code) for links to the UI
 settings and let the user lock it down or open it up from where it is
 now.
> Yes, I was referring to this and to Peter's ideas.
>
>>> Yes, but that will only work for trunk/AOO42X since we need to update
>>> the translations too.
> I agree, but how many 4.1.X versions do we want to publish before 4.2.0?
> Now that we support two digits, please let us not point to 4.1.99 ! ;-)

As "soon" as all Release Blocker are fixed we can release 4.2.0 ;-)

Regards,

   Matthias

>
> Best regards,



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Peter Kovacs]

On 14.05.21 07:27, Arrigo Marchiori wrote:

Yes, but that will only work for trunk/AOO42X since we need to update

the translations too.

I agree, but how many 4.1.X versions do we want to publish before 4.2.0?
Now that we support two digits, please let us not point to 4.1.99 ! ;-)


We all want that 4.2.0 will be in shape for release fast.

However unless we start fixing the Windows regressions in 4.2.0 we are 
stuck with 4.1.X.


And currently, to my knowledge, only Matthias is able to build a Windows 
Version.



All the best

Peter

--
This is the Way! http://www.apache.org/theapacheway/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Hello Carl, all,

On Thu, May 13, 2021 at 07:23:16PM -0400, Carl Marcum wrote:

[...]

> Hopefully we can collect the exceptions in the BZ issue noted in this thread
> and then agree on the direction.
> 
> The few I see so far are:
> 1. in-document links beginning with #.
> 2. .uno:XXX links
> 3. Links to local files.
> 
> I think all 3 are candidates but that's just me.
> 
> @Arrigo, were you planning on a PR for AOO41X ?
> 
> If not, I can try at least some of it but again I'm not really a C++ guy yet
> :)

I suggest we make up our minds on the intended solution first, and
then start coding it. We have seen some interesting proposals, some of
which were quite complex (adding configuration settings, dialogs etc).

The three categories listed above would be candidates for
whitelisting, and this would be the quickest fix. But someone fluent
in UNO should first ensure all of us that no.2 is not going to reopen
any other backdoors!

Maybe this topic is worth a discussion with vote, the Apache way? So
we get our roadmap fixed.

> > > There is also the suggestion (Dave's maybe?) that we add the 3
> > > security levels (that are already in the code) for links to the UI
> > > settings and let the user lock it down or open it up from where it is
> > > now.

Yes, I was referring to this and to Peter's ideas.

> > Yes, but that will only work for trunk/AOO42X since we need to update
> > the translations too.

I agree, but how many 4.1.X versions do we want to publish before 4.2.0?
Now that we support two digits, please let us not point to 4.1.99 ! ;-)

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Matthias,

On 5/13/21 6:32 PM, Matthias Seidel wrote:

Hi Carl,

Am 14.05.21 um 00:26 schrieb Carl Marcum:

Hi Matthias,

On 5/13/21 9:23 AM, Matthias Seidel wrote:

Hi Carl,

Am 13.05.21 um 13:05 schrieb Carl Marcum:

Hi All,

On 5/13/21 3:01 AM, Peter Kovacs wrote:

Does it make sense in addition to create a Wiki page with all types
of Links that we can have?

So we have some sort of Documentation.

Also maybe the ODF specification can give us hints what type there is.

On 12.05.21 22:12, Arrigo Marchiori wrote:

Hello all,

please allow me to top-post as I just need a ``public reminder''.

An Italian user reported another problem [1]: they have links that
point _to the same document_ and trigger the warning.

Even if you do not understand Italian, you can download the
attachment
and look at what the buttons do.

URLs are in the form: "#anchor". Therefore, we should remember to
whitelist all links starting with "#", whatever design choice we
make.

Would not it be nice to file a BugZilla issue to collect all the
reports and URLs, as it happened for other ``popular'' bugs?

1: https://forum.openoffice.org/it/forum/viewtopic.php?f=9=11231

Best regards,

There seem to be quite a lot.

We should probably decide what we're going to allow.
One list I found is in urlobj.cxx [1].

Not sure yet what the differences are in internal, external, and
official and if that may help decide.

I see that INET_PROT_UNO is available.
Maybe that can be allowed the same way as INET_PROT_VND_SUN_STAR_HELP?


Yes that's probably going to be one.

If you have an idea for AOO41X, can you provide a PR? I will then build
for Windows to let people test.


Hopefully we can collect the exceptions in the BZ issue noted in this 
thread and then agree on the direction.


The few I see so far are:
1. in-document links beginning with #.
2. .uno:XXX links
3. Links to local files.

I think all 3 are candidates but that's just me.

@Arrigo, were you planning on a PR for AOO41X ?

If not, I can try at least some of it but again I'm not really a C++ guy 
yet :)


Best regards,
Carl

There is also the suggestion (Dave's maybe?) that we add the 3
security levels (that are already in the code) for links to the UI
settings and let the user lock it down or open it up from where it is
now.

Yes, but that will only work for trunk/AOO42X since we need to update
the translations too.

Regards,

    Matthias


I'm not yet familiar with the UI code to know where to begin.

Best regards,
Carl


Regards,

    Matthias


[1]
http://opengrok.openoffice.org/xref/trunk/main/tools/source/fsys/urlobj.cxx?r=86e1cf34#2080


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Carl,

Am 14.05.21 um 00:26 schrieb Carl Marcum:
> Hi Matthias,
>
> On 5/13/21 9:23 AM, Matthias Seidel wrote:
>>
>> Hi Carl,
>>
>> Am 13.05.21 um 13:05 schrieb Carl Marcum:
>>> Hi All,
>>>
>>> On 5/13/21 3:01 AM, Peter Kovacs wrote:
 Does it make sense in addition to create a Wiki page with all types
 of Links that we can have?

 So we have some sort of Documentation.

 Also maybe the ODF specification can give us hints what type there is.

 On 12.05.21 22:12, Arrigo Marchiori wrote:
> Hello all,
>
> please allow me to top-post as I just need a ``public reminder''.
>
> An Italian user reported another problem [1]: they have links that
> point _to the same document_ and trigger the warning.
>
> Even if you do not understand Italian, you can download the
> attachment
> and look at what the buttons do.
>
> URLs are in the form: "#anchor". Therefore, we should remember to
> whitelist all links starting with "#", whatever design choice we
> make.
>
> Would not it be nice to file a BugZilla issue to collect all the
> reports and URLs, as it happened for other ``popular'' bugs?
>
> 1: https://forum.openoffice.org/it/forum/viewtopic.php?f=9=11231
>
> Best regards,
>>> There seem to be quite a lot.
>>>
>>> We should probably decide what we're going to allow.
>>> One list I found is in urlobj.cxx [1].
>>>
>>> Not sure yet what the differences are in internal, external, and
>>> official and if that may help decide.
>>
>> I see that INET_PROT_UNO is available.
>> Maybe that can be allowed the same way as INET_PROT_VND_SUN_STAR_HELP?
>>
> Yes that's probably going to be one.
If you have an idea for AOO41X, can you provide a PR? I will then build
for Windows to let people test.
>
> There is also the suggestion (Dave's maybe?) that we add the 3
> security levels (that are already in the code) for links to the UI
> settings and let the user lock it down or open it up from where it is
> now.

Yes, but that will only work for trunk/AOO42X since we need to update
the translations too.

Regards,

   Matthias

>
> I'm not yet familiar with the UI code to know where to begin.
>
> Best regards,
> Carl
>
>> Regards,
>>
>>    Matthias
>>
>>>
>>> [1]
>>> http://opengrok.openoffice.org/xref/trunk/main/tools/source/fsys/urlobj.cxx?r=86e1cf34#2080
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Matthias,

On 5/13/21 9:23 AM, Matthias Seidel wrote:


Hi Carl,

Am 13.05.21 um 13:05 schrieb Carl Marcum:

Hi All,

On 5/13/21 3:01 AM, Peter Kovacs wrote:
Does it make sense in addition to create a Wiki page with all types 
of Links that we can have?


So we have some sort of Documentation.

Also maybe the ODF specification can give us hints what type there is.

On 12.05.21 22:12, Arrigo Marchiori wrote:

Hello all,

please allow me to top-post as I just need a ``public reminder''.

An Italian user reported another problem [1]: they have links that
point _to the same document_ and trigger the warning.

Even if you do not understand Italian, you can download the attachment
and look at what the buttons do.

URLs are in the form: "#anchor". Therefore, we should remember to
whitelist all links starting with "#", whatever design choice we make.

Would not it be nice to file a BugZilla issue to collect all the
reports and URLs, as it happened for other ``popular'' bugs?

1: https://forum.openoffice.org/it/forum/viewtopic.php?f=9=11231

Best regards,

There seem to be quite a lot.

We should probably decide what we're going to allow.
One list I found is in urlobj.cxx [1].

Not sure yet what the differences are in internal, external, and 
official and if that may help decide.


I see that INET_PROT_UNO is available.
Maybe that can be allowed the same way as INET_PROT_VND_SUN_STAR_HELP?


Yes that's probably going to be one.

There is also the suggestion (Dave's maybe?) that we add the 3 security 
levels (that are already in the code) for links to the UI settings and 
let the user lock it down or open it up from where it is now.


I'm not yet familiar with the UI code to know where to begin.

Best regards,
Carl


Regards,

   Matthias



[1] 
http://opengrok.openoffice.org/xref/trunk/main/tools/source/fsys/urlobj.cxx?r=86e1cf34#2080



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Carl,

Am 13.05.21 um 13:05 schrieb Carl Marcum:
> Hi All,
>
> On 5/13/21 3:01 AM, Peter Kovacs wrote:
>> Does it make sense in addition to create a Wiki page with all types
>> of Links that we can have?
>>
>> So we have some sort of Documentation.
>>
>> Also maybe the ODF specification can give us hints what type there is.
>>
>> On 12.05.21 22:12, Arrigo Marchiori wrote:
>>> Hello all,
>>>
>>> please allow me to top-post as I just need a ``public reminder''.
>>>
>>> An Italian user reported another problem [1]: they have links that
>>> point _to the same document_ and trigger the warning.
>>>
>>> Even if you do not understand Italian, you can download the attachment
>>> and look at what the buttons do.
>>>
>>> URLs are in the form: "#anchor". Therefore, we should remember to
>>> whitelist all links starting with "#", whatever design choice we make.
>>>
>>> Would not it be nice to file a BugZilla issue to collect all the
>>> reports and URLs, as it happened for other ``popular'' bugs?
>>>
>>> 1: https://forum.openoffice.org/it/forum/viewtopic.php?f=9=11231
>>>
>>> Best regards,
> There seem to be quite a lot.
>
> We should probably decide what we're going to allow.
> One list I found is in urlobj.cxx [1].
>
> Not sure yet what the differences are in internal, external, and
> official and if that may help decide.

I see that INET_PROT_UNO is available.
Maybe that can be allowed the same way as INET_PROT_VND_SUN_STAR_HELP?

Regards,

   Matthias

>
> [1]
> http://opengrok.openoffice.org/xref/trunk/main/tools/source/fsys/urlobj.cxx?r=86e1cf34#2080
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Carl Marcum]

Hi All,

On 5/13/21 3:01 AM, Peter Kovacs wrote:
Does it make sense in addition to create a Wiki page with all types of 
Links that we can have?


So we have some sort of Documentation.

Also maybe the ODF specification can give us hints what type there is.

On 12.05.21 22:12, Arrigo Marchiori wrote:

Hello all,

please allow me to top-post as I just need a ``public reminder''.

An Italian user reported another problem [1]: they have links that
point _to the same document_ and trigger the warning.

Even if you do not understand Italian, you can download the attachment
and look at what the buttons do.

URLs are in the form: "#anchor". Therefore, we should remember to
whitelist all links starting with "#", whatever design choice we make.

Would not it be nice to file a BugZilla issue to collect all the
reports and URLs, as it happened for other ``popular'' bugs?

1: https://forum.openoffice.org/it/forum/viewtopic.php?f=9=11231

Best regards,

There seem to be quite a lot.

We should probably decide what we're going to allow.
One list I found is in urlobj.cxx [1].

Not sure yet what the differences are in internal, external, and 
official and if that may help decide.


[1] 
http://opengrok.openoffice.org/xref/trunk/main/tools/source/fsys/urlobj.cxx?r=86e1cf34#2080



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Peter Kovacs]

Does it make sense in addition to create a Wiki page with all types of 
Links that we can have?


So we have some sort of Documentation.

Also maybe the ODF specification can give us hints what type there is.

On 12.05.21 22:12, Arrigo Marchiori wrote:

Hello all,

please allow me to top-post as I just need a ``public reminder''.

An Italian user reported another problem [1]: they have links that
point _to the same document_ and trigger the warning.

Even if you do not understand Italian, you can download the attachment
and look at what the buttons do.

URLs are in the form: "#anchor". Therefore, we should remember to
whitelist all links starting with "#", whatever design choice we make.

Would not it be nice to file a BugZilla issue to collect all the
reports and URLs, as it happened for other ``popular'' bugs?

1: https://forum.openoffice.org/it/forum/viewtopic.php?f=9=11231

Best regards,

--
This is the Way! http://www.apache.org/theapacheway/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Hello Marcus, all,

On Wed, May 12, 2021 at 10:17:22PM +0200, Marcus wrote:

> Am 12.05.21 um 22:12 schrieb Arrigo Marchiori:
> > please allow me to top-post as I just need a ``public reminder''.

Thank you for your patience

> > An Italian user reported another problem [1]: they have links that
> > point _to the same document_ and trigger the warning.

And thanks to Czesław Wołanski for bringing it to my attention!

> > Even if you do not understand Italian, you can download the attachment
> > and look at what the buttons do.
> > 
> > URLs are in the form: "#anchor". Therefore, we should remember to
> > whitelist all links starting with "#", whatever design choice we make.
> 
> yes, good point.
> 
> > Would not it be nice to file a BugZilla issue to collect all the
> > reports and URLs, as it happened for other ``popular'' bugs?
> > 
> > 1: https://forum.openoffice.org/it/forum/viewtopic.php?f=9=11231
> 
> I don't think that we need another issue for the problem. Why not using this
> one [2] and extend it by comments which URL parts we also want to consider:
> 
> [2] https://bz.apache.org/ooo/show_bug.cgi?id=128453

Ok. Will do!

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Marcus]

Am 12.05.21 um 22:12 schrieb Arrigo Marchiori:

please allow me to top-post as I just need a ``public reminder''.

An Italian user reported another problem [1]: they have links that
point _to the same document_ and trigger the warning.

Even if you do not understand Italian, you can download the attachment
and look at what the buttons do.

URLs are in the form: "#anchor". Therefore, we should remember to
whitelist all links starting with "#", whatever design choice we make.


yes, good point.


Would not it be nice to file a BugZilla issue to collect all the
reports and URLs, as it happened for other ``popular'' bugs?

1: https://forum.openoffice.org/it/forum/viewtopic.php?f=9=11231


I don't think that we need another issue for the problem. Why not using 
this one [2] and extend it by comments which URL parts we also want to 
consider:


[2] https://bz.apache.org/ooo/show_bug.cgi?id=128453

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Hello all,

please allow me to top-post as I just need a ``public reminder''.

An Italian user reported another problem [1]: they have links that
point _to the same document_ and trigger the warning.

Even if you do not understand Italian, you can download the attachment
and look at what the buttons do.

URLs are in the form: "#anchor". Therefore, we should remember to
whitelist all links starting with "#", whatever design choice we make.

Would not it be nice to file a BugZilla issue to collect all the
reports and URLs, as it happened for other ``popular'' bugs?

1: https://forum.openoffice.org/it/forum/viewtopic.php?f=9=11231

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Matthias Seidel]

Hi Ken,

Am 12.05.21 um 09:32 schrieb k...@kshelton.plus.com:
> Hello Marcus
>
> Thanks for your prompt reply.
>
> We also have a ‘Close’ button in our document and this now also gives the 
> same warning.   The 'Reload' button is used regularly through the day as 
> there is more than one person editing the document.   We would certainly 
> appreciate being able to switch off this warning.

What operating system are you using?

If Windows, would you be interested in Test builds, in case we have code
updates?

Regards,

   Matthias

>
> Thanks again.
>
> Regards
> Keith Shelton
>
>> On 4 May 2021, at 17:33, Marcus  wrote:
>>
>> Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
>>> For some years I've had a Reload button in my Calc document to avoid having 
>>> to use the File menu. Just updated to 4.1.10 and now I get a message when 
>>> pressing Reload button:
>>> This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
>>> Is there a way of switching off this message please?
>> unfortunately, there is no option to turn it off.
>>
>> And I think that the use case you have reported happens very often, so a 
>> solution would be very helpful. ;-)
>>
>> Marcus
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Hyperlink Warning Message

[Carl Marcum]

Hi Ken,

I see your Reload button is using an UNO call.
What is the text of the warning when you use your Close button.

Are these buttons using your macros or was it an extension you added?

Thanks,
Carl

On 5/12/21 3:32 AM, k...@kshelton.plus.com wrote:

Hello Marcus

Thanks for your prompt reply.

We also have a ‘Close’ button in our document and this now also gives the same 
warning.   The 'Reload' button is used regularly through the day as there is 
more than one person editing the document.   We would certainly appreciate 
being able to switch off this warning.

Thanks again.

Regards
Keith Shelton


On 4 May 2021, at 17:33, Marcus  wrote:

Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:

For some years I've had a Reload button in my Calc document to avoid having to 
use the File menu. Just updated to 4.1.10 and now I get a message when pressing 
Reload button:
This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
Is there a way of switching off this message please?

unfortunately, there is no option to turn it off.

And I think that the use case you have reported happens very often, so a 
solution would be very helpful. ;-)

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Hyperlink Warning Message

[ken]

Hello Marcus

Thanks for your prompt reply.

We also have a ‘Close’ button in our document and this now also gives the same 
warning.   The 'Reload' button is used regularly through the day as there is 
more than one person editing the document.   We would certainly appreciate 
being able to switch off this warning.

Thanks again.

Regards
Keith Shelton

> On 4 May 2021, at 17:33, Marcus  wrote:
> 
> Am 04.05.21 um 16:05 schrieb k...@kshelton.plus.com:
>> For some years I've had a Reload button in my Calc document to avoid having 
>> to use the File menu. Just updated to 4.1.10 and now I get a message when 
>> pressing Reload button:
>> This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
>> Is there a way of switching off this message please?
> 
> unfortunately, there is no option to turn it off.
> 
> And I think that the use case you have reported happens very often, so a 
> solution would be very helpful. ;-)
> 
> Marcus
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)

[Matthias Seidel]

Thanks!

Am 11.05.21 um 20:04 schrieb Jim Jagielski:
> Done
>
>> On May 11, 2021, at 1:53 PM, Jim Jagielski  wrote:
>>
>> Will do... 
>>
>>> On May 10, 2021, at 2:49 PM, Marcus  wrote:
>>>
>>> Am 06.05.21 um 15:50 schrieb Matthias Seidel:
 Am 06.05.21 um 15:08 schrieb Jim Jagielski:
> Once we tag HEAD of AOO41X to AOO4110
 Can't wait! ;-)
 I have dozens of commits to be backported to AOO41X...
>>> @Jim:
>>> Can you please create the release tag from the 41X branch? Then we can 
>>> close the relase schedule for 4.1.10.
>>>
>>> Thanksa
>>>
>>> Marcus
>>>
>>>
>>>
>> On May 6, 2021, at 8:28 AM, Matthias Seidel  
>> wrote:
>>
>> Hi all,
>>
>> Just a pragmatic question:
>>
>> When do we want to start working on AOO 4.1.11?
>>
>> The sooner we branch it, the sooner we can do Test builds and let people
>> see if their problem is fixed...
>>
>> Matthias
>>
>> Am 05.05.21 um 23:31 schrieb Peter Kovacs:
>>> On 05.05.21 22:11, Arrigo Marchiori wrote:
 Hello Peter, all,

 On Wed, May 05, 2021 at 05:44:17PM +, Peter Kovacs wrote:

> On 05.05.21 14:37, Arrigo Marchiori wrote:
>> Hello,
>>
>> On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:
>>
>>> The best approach I believe is to add a whitelist feature as for
>>> macro
>>> files.
>>>
>>> Users can add then the links they wish to approve.
>> Do you mean file-based whitelists instead of target-based?
>>
>> I will try to explain myself better: the current filter on AOO 4.1.10
>> is target-based, because it is the target of the link that triggers
>> the warning. Are you suggesting to add a whitelist based on files, 
>> for
>> example "allow any links in documents from this directory"?
>>
>> If so, would you use the same whitelist as for macros, or would you
>> introduce another one?
> I do not think that it makes sense to allow
> https://my.payload.crime/AOO_diskscrambler.ods to be seen as save
> target for
> opening and macro execution at the same time.
>
> Better is to have both separated. And the simple practicable
> solution is to
> just add an own list which allows targets to be listed.
 I see.  But please let us distinguish targets and sources.
>>> Well, yea this is a nice abstraction I did not make. Good one.
 The macros' whitelist contains _directories_ (I don't really like
 calling them folders, I hope you don't mind) whose files are trusted,
 with respect to macro execution.
>>> sure. Names are sound and smoke ;) - sorry can not resist this german
>>> IT idiom.
 In your reply above you seem to discuss a whitelist of _link targets_?
 Not documents, containing links that shall always be followed?
>>> Yes, I thought on the target of the link. For me was this the
>>> important trait.
>>>
>>> However if I think in which document I grant the security level. Hmm,
>>> I think this makes the whole concept a lot easier.
>>>
>>> Plus we would then one list. So we extend an existing feature.
>>>
> If we would want to have a vision, where we should develop to, this
> would be
> mine:
>
> We have One list and 2 properties. 1 property for hyperlink
> whitelisting,
> the other one for (macro) execution. I like our 4 security stages.
 The four security levels currently available for macros, if I
 understand correctly, are based on a combination of:

  - digital signatures of the macros (signed or not),
  - trust of certain digital signatures (certificate trusted or not),
  - position of the document (directory whitelisted or not).

 This is... quite complex IMHO.
>>> That why I have written it is maybe a vision. And maybe it is to much.
 Did you refer exactly to this model?
>>> yes kind of. I thought that a hyperlink has some sort of certiicate
>>> and an macro can have some certification and that is kind of the same
>>> thing...
 Or
 shall we rather adopt a simpler one for links, for example only
 considering the directories whitelist?
>>> Now that I think on your approach I think we should only look at the
>>> directory that the document has been opened from. But still I would
>>> still rather configure it per directory, then in a general and work
>>> with exclusions.
>>>
>>> However this is maybe not so smart to implement now, since our profile
>>> is not robust enough. It will break eventually, and then all nice
>>> settings are lost. And that is not something I would like to have.
>>>
 And to understand better: does AOO allow to 

Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)

[Jim Jagielski]

Done

> On May 11, 2021, at 1:53 PM, Jim Jagielski  wrote:
> 
> Will do... 
> 
>> On May 10, 2021, at 2:49 PM, Marcus  wrote:
>> 
>> Am 06.05.21 um 15:50 schrieb Matthias Seidel:
>>> Am 06.05.21 um 15:08 schrieb Jim Jagielski:
 Once we tag HEAD of AOO41X to AOO4110
>>> Can't wait! ;-)
>>> I have dozens of commits to be backported to AOO41X...
>> 
>> @Jim:
>> Can you please create the release tag from the 41X branch? Then we can close 
>> the relase schedule for 4.1.10.
>> 
>> Thanksa
>> 
>> Marcus
>> 
>> 
>> 
> On May 6, 2021, at 8:28 AM, Matthias Seidel  
> wrote:
> 
> Hi all,
> 
> Just a pragmatic question:
> 
> When do we want to start working on AOO 4.1.11?
> 
> The sooner we branch it, the sooner we can do Test builds and let people
> see if their problem is fixed...
> 
> Matthias
> 
> Am 05.05.21 um 23:31 schrieb Peter Kovacs:
>> On 05.05.21 22:11, Arrigo Marchiori wrote:
>>> Hello Peter, all,
>>> 
>>> On Wed, May 05, 2021 at 05:44:17PM +, Peter Kovacs wrote:
>>> 
 On 05.05.21 14:37, Arrigo Marchiori wrote:
> Hello,
> 
> On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:
> 
>> The best approach I believe is to add a whitelist feature as for
>> macro
>> files.
>> 
>> Users can add then the links they wish to approve.
> Do you mean file-based whitelists instead of target-based?
> 
> I will try to explain myself better: the current filter on AOO 4.1.10
> is target-based, because it is the target of the link that triggers
> the warning. Are you suggesting to add a whitelist based on files, for
> example "allow any links in documents from this directory"?
> 
> If so, would you use the same whitelist as for macros, or would you
> introduce another one?
 I do not think that it makes sense to allow
 https://my.payload.crime/AOO_diskscrambler.ods to be seen as save
 target for
 opening and macro execution at the same time.
 
 Better is to have both separated. And the simple practicable
 solution is to
 just add an own list which allows targets to be listed.
>>> I see.  But please let us distinguish targets and sources.
>> Well, yea this is a nice abstraction I did not make. Good one.
>>> The macros' whitelist contains _directories_ (I don't really like
>>> calling them folders, I hope you don't mind) whose files are trusted,
>>> with respect to macro execution.
>> sure. Names are sound and smoke ;) - sorry can not resist this german
>> IT idiom.
>>> In your reply above you seem to discuss a whitelist of _link targets_?
>>> Not documents, containing links that shall always be followed?
>> Yes, I thought on the target of the link. For me was this the
>> important trait.
>> 
>> However if I think in which document I grant the security level. Hmm,
>> I think this makes the whole concept a lot easier.
>> 
>> Plus we would then one list. So we extend an existing feature.
>> 
 If we would want to have a vision, where we should develop to, this
 would be
 mine:
 
 We have One list and 2 properties. 1 property for hyperlink
 whitelisting,
 the other one for (macro) execution. I like our 4 security stages.
>>> The four security levels currently available for macros, if I
>>> understand correctly, are based on a combination of:
>>> 
>>>  - digital signatures of the macros (signed or not),
>>>  - trust of certain digital signatures (certificate trusted or not),
>>>  - position of the document (directory whitelisted or not).
>>> 
>>> This is... quite complex IMHO.
>> That why I have written it is maybe a vision. And maybe it is to much.
>>> Did you refer exactly to this model?
>> yes kind of. I thought that a hyperlink has some sort of certiicate
>> and an macro can have some certification and that is kind of the same
>> thing...
>>> Or
>>> shall we rather adopt a simpler one for links, for example only
>>> considering the directories whitelist?
>> Now that I think on your approach I think we should only look at the
>> directory that the document has been opened from. But still I would
>> still rather configure it per directory, then in a general and work
>> with exclusions.
>> 
>> However this is maybe not so smart to implement now, since our profile
>> is not robust enough. It will break eventually, and then all nice
>> settings are lost. And that is not something I would like to have.
>> 
>>> And to understand better: does AOO allow to sign individual macros? Or
>>> just the document containing them? I don't think that it allows to
>>> sign individual links within a document.

Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)

[Jim Jagielski]

Will do... 

> On May 10, 2021, at 2:49 PM, Marcus  wrote:
> 
> Am 06.05.21 um 15:50 schrieb Matthias Seidel:
>> Am 06.05.21 um 15:08 schrieb Jim Jagielski:
>>> Once we tag HEAD of AOO41X to AOO4110
>> Can't wait! ;-)
>> I have dozens of commits to be backported to AOO41X...
> 
> @Jim:
> Can you please create the release tag from the 41X branch? Then we can close 
> the relase schedule for 4.1.10.
> 
> Thanksa
> 
> Marcus
> 
> 
> 
 On May 6, 2021, at 8:28 AM, Matthias Seidel  
 wrote:
 
 Hi all,
 
 Just a pragmatic question:
 
 When do we want to start working on AOO 4.1.11?
 
 The sooner we branch it, the sooner we can do Test builds and let people
 see if their problem is fixed...
 
 Matthias
 
 Am 05.05.21 um 23:31 schrieb Peter Kovacs:
> On 05.05.21 22:11, Arrigo Marchiori wrote:
>> Hello Peter, all,
>> 
>> On Wed, May 05, 2021 at 05:44:17PM +, Peter Kovacs wrote:
>> 
>>> On 05.05.21 14:37, Arrigo Marchiori wrote:
 Hello,
 
 On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:
 
> The best approach I believe is to add a whitelist feature as for
> macro
> files.
> 
> Users can add then the links they wish to approve.
 Do you mean file-based whitelists instead of target-based?
 
 I will try to explain myself better: the current filter on AOO 4.1.10
 is target-based, because it is the target of the link that triggers
 the warning. Are you suggesting to add a whitelist based on files, for
 example "allow any links in documents from this directory"?
 
 If so, would you use the same whitelist as for macros, or would you
 introduce another one?
>>> I do not think that it makes sense to allow
>>> https://my.payload.crime/AOO_diskscrambler.ods to be seen as save
>>> target for
>>> opening and macro execution at the same time.
>>> 
>>> Better is to have both separated. And the simple practicable
>>> solution is to
>>> just add an own list which allows targets to be listed.
>> I see.  But please let us distinguish targets and sources.
> Well, yea this is a nice abstraction I did not make. Good one.
>> The macros' whitelist contains _directories_ (I don't really like
>> calling them folders, I hope you don't mind) whose files are trusted,
>> with respect to macro execution.
> sure. Names are sound and smoke ;) - sorry can not resist this german
> IT idiom.
>> In your reply above you seem to discuss a whitelist of _link targets_?
>> Not documents, containing links that shall always be followed?
> Yes, I thought on the target of the link. For me was this the
> important trait.
> 
> However if I think in which document I grant the security level. Hmm,
> I think this makes the whole concept a lot easier.
> 
> Plus we would then one list. So we extend an existing feature.
> 
>>> If we would want to have a vision, where we should develop to, this
>>> would be
>>> mine:
>>> 
>>> We have One list and 2 properties. 1 property for hyperlink
>>> whitelisting,
>>> the other one for (macro) execution. I like our 4 security stages.
>> The four security levels currently available for macros, if I
>> understand correctly, are based on a combination of:
>> 
>>   - digital signatures of the macros (signed or not),
>>   - trust of certain digital signatures (certificate trusted or not),
>>   - position of the document (directory whitelisted or not).
>> 
>> This is... quite complex IMHO.
> That why I have written it is maybe a vision. And maybe it is to much.
>> Did you refer exactly to this model?
> yes kind of. I thought that a hyperlink has some sort of certiicate
> and an macro can have some certification and that is kind of the same
> thing...
>> Or
>> shall we rather adopt a simpler one for links, for example only
>> considering the directories whitelist?
> Now that I think on your approach I think we should only look at the
> directory that the document has been opened from. But still I would
> still rather configure it per directory, then in a general and work
> with exclusions.
> 
> However this is maybe not so smart to implement now, since our profile
> is not robust enough. It will break eventually, and then all nice
> settings are lost. And that is not something I would like to have.
> 
>> And to understand better: does AOO allow to sign individual macros? Or
>> just the document containing them? I don't think that it allows to
>> sign individual links within a document.
> No it would not sign individual links on the document.- But don't we
> have document signing?
> 
> For links we could check if the document is signed.
> 
> 

Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)

[Matthias Seidel]

Am 10.05.21 um 20:49 schrieb Marcus:
> Am 06.05.21 um 15:50 schrieb Matthias Seidel:
>> Am 06.05.21 um 15:08 schrieb Jim Jagielski:
>>> Once we tag HEAD of AOO41X to AOO4110
>>
>> Can't wait! ;-)
>>
>> I have dozens of commits to be backported to AOO41X...
>
> @Jim:
> Can you please create the release tag from the 41X branch? Then we can
> close the relase schedule for 4.1.10.

+1

Can we move on?

Matthias

>
> Thanksa
>
> Marcus
>
>
>
 On May 6, 2021, at 8:28 AM, Matthias Seidel
  wrote:

 Hi all,

 Just a pragmatic question:

 When do we want to start working on AOO 4.1.11?

 The sooner we branch it, the sooner we can do Test builds and let
 people
 see if their problem is fixed...

 Matthias

 Am 05.05.21 um 23:31 schrieb Peter Kovacs:
> On 05.05.21 22:11, Arrigo Marchiori wrote:
>> Hello Peter, all,
>>
>> On Wed, May 05, 2021 at 05:44:17PM +, Peter Kovacs wrote:
>>
>>> On 05.05.21 14:37, Arrigo Marchiori wrote:
 Hello,

 On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:

> The best approach I believe is to add a whitelist feature as for
> macro
> files.
>
> Users can add then the links they wish to approve.
 Do you mean file-based whitelists instead of target-based?

 I will try to explain myself better: the current filter on AOO
 4.1.10
 is target-based, because it is the target of the link that
 triggers
 the warning. Are you suggesting to add a whitelist based on
 files, for
 example "allow any links in documents from this directory"?

 If so, would you use the same whitelist as for macros, or would
 you
 introduce another one?
>>> I do not think that it makes sense to allow
>>> https://my.payload.crime/AOO_diskscrambler.ods to be seen as save
>>> target for
>>> opening and macro execution at the same time.
>>>
>>> Better is to have both separated. And the simple practicable
>>> solution is to
>>> just add an own list which allows targets to be listed.
>> I see.  But please let us distinguish targets and sources.
> Well, yea this is a nice abstraction I did not make. Good one.
>> The macros' whitelist contains _directories_ (I don't really like
>> calling them folders, I hope you don't mind) whose files are
>> trusted,
>> with respect to macro execution.
> sure. Names are sound and smoke ;) - sorry can not resist this german
> IT idiom.
>> In your reply above you seem to discuss a whitelist of _link
>> targets_?
>> Not documents, containing links that shall always be followed?
> Yes, I thought on the target of the link. For me was this the
> important trait.
>
> However if I think in which document I grant the security level. Hmm,
> I think this makes the whole concept a lot easier.
>
> Plus we would then one list. So we extend an existing feature.
>
>>> If we would want to have a vision, where we should develop to, this
>>> would be
>>> mine:
>>>
>>> We have One list and 2 properties. 1 property for hyperlink
>>> whitelisting,
>>> the other one for (macro) execution. I like our 4 security stages.
>> The four security levels currently available for macros, if I
>> understand correctly, are based on a combination of:
>>
>>    - digital signatures of the macros (signed or not),
>>    - trust of certain digital signatures (certificate trusted or
>> not),
>>    - position of the document (directory whitelisted or not).
>>
>> This is... quite complex IMHO.
> That why I have written it is maybe a vision. And maybe it is to
> much.
>> Did you refer exactly to this model?
> yes kind of. I thought that a hyperlink has some sort of certiicate
> and an macro can have some certification and that is kind of the same
> thing...
>> Or
>> shall we rather adopt a simpler one for links, for example only
>> considering the directories whitelist?
> Now that I think on your approach I think we should only look at the
> directory that the document has been opened from. But still I would
> still rather configure it per directory, then in a general and work
> with exclusions.
>
> However this is maybe not so smart to implement now, since our
> profile
> is not robust enough. It will break eventually, and then all nice
> settings are lost. And that is not something I would like to have.
>
>> And to understand better: does AOO allow to sign individual
>> macros? Or
>> just the document containing them? I don't think that it allows to
>> sign individual links within a document.
> No it would not sign individual links on the document.- But don't we
> have document signing?
>

Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)

[Marcus]

Am 06.05.21 um 15:50 schrieb Matthias Seidel:

Am 06.05.21 um 15:08 schrieb Jim Jagielski:

Once we tag HEAD of AOO41X to AOO4110


Can't wait! ;-)

I have dozens of commits to be backported to AOO41X...


@Jim:
Can you please create the release tag from the 41X branch? Then we can 
close the relase schedule for 4.1.10.


Thanksa

Marcus




On May 6, 2021, at 8:28 AM, Matthias Seidel  wrote:

Hi all,

Just a pragmatic question:

When do we want to start working on AOO 4.1.11?

The sooner we branch it, the sooner we can do Test builds and let people
see if their problem is fixed...

Matthias

Am 05.05.21 um 23:31 schrieb Peter Kovacs:

On 05.05.21 22:11, Arrigo Marchiori wrote:

Hello Peter, all,

On Wed, May 05, 2021 at 05:44:17PM +, Peter Kovacs wrote:


On 05.05.21 14:37, Arrigo Marchiori wrote:

Hello,

On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:


The best approach I believe is to add a whitelist feature as for
macro
files.

Users can add then the links they wish to approve.

Do you mean file-based whitelists instead of target-based?

I will try to explain myself better: the current filter on AOO 4.1.10
is target-based, because it is the target of the link that triggers
the warning. Are you suggesting to add a whitelist based on files, for
example "allow any links in documents from this directory"?

If so, would you use the same whitelist as for macros, or would you
introduce another one?

I do not think that it makes sense to allow
https://my.payload.crime/AOO_diskscrambler.ods to be seen as save
target for
opening and macro execution at the same time.

Better is to have both separated. And the simple practicable
solution is to
just add an own list which allows targets to be listed.

I see.  But please let us distinguish targets and sources.

Well, yea this is a nice abstraction I did not make. Good one.

The macros' whitelist contains _directories_ (I don't really like
calling them folders, I hope you don't mind) whose files are trusted,
with respect to macro execution.

sure. Names are sound and smoke ;) - sorry can not resist this german
IT idiom.

In your reply above you seem to discuss a whitelist of _link targets_?
Not documents, containing links that shall always be followed?

Yes, I thought on the target of the link. For me was this the
important trait.

However if I think in which document I grant the security level. Hmm,
I think this makes the whole concept a lot easier.

Plus we would then one list. So we extend an existing feature.


If we would want to have a vision, where we should develop to, this
would be
mine:

We have One list and 2 properties. 1 property for hyperlink
whitelisting,
the other one for (macro) execution. I like our 4 security stages.

The four security levels currently available for macros, if I
understand correctly, are based on a combination of:

   - digital signatures of the macros (signed or not),
   - trust of certain digital signatures (certificate trusted or not),
   - position of the document (directory whitelisted or not).

This is... quite complex IMHO.

That why I have written it is maybe a vision. And maybe it is to much.

Did you refer exactly to this model?

yes kind of. I thought that a hyperlink has some sort of certiicate
and an macro can have some certification and that is kind of the same
thing...

Or
shall we rather adopt a simpler one for links, for example only
considering the directories whitelist?

Now that I think on your approach I think we should only look at the
directory that the document has been opened from. But still I would
still rather configure it per directory, then in a general and work
with exclusions.

However this is maybe not so smart to implement now, since our profile
is not robust enough. It will break eventually, and then all nice
settings are lost. And that is not something I would like to have.


And to understand better: does AOO allow to sign individual macros? Or
just the document containing them? I don't think that it allows to
sign individual links within a document.

No it would not sign individual links on the document.- But don't we
have document signing?

For links we could check if the document is signed.


So summing up:

# Instead of checking where the hyperlink is refering to, only check
where the document has been stored. (Treat hyperlinks as macros so to
say.)

# As an enhancement we could add a model that checks for the nearest
applicable path to the document, and applies that rule.


Example for a customized setup on a POSIX filesystem (security level
3 =
very high and 0 = low; first value is hyperlink, second value is macro
execution of this origin):

/tmp  (3,3) => Everything in the temp folder does not open links or
execute
macros

~/ (2,2) => something that is within the home path, but not a folder
listed
below, may execute signed macros or open targets that have a trusted
certificate

~/Downloads (2,3) => Downloads may open Links with a trusted
certificate but
not allow to 

Re: Hyperlink Warning Message

[Peter Kovacs]

ok, nice write up.

On 07.05.21 07:38, Dave Fisher wrote:

Hi -

The discussion should proceed considering how appopen.cpp is actually coded. 
I’m writing from memory so you will need to match my description to the actual 
variables and constants


On May 5, 2021, at 5:37 AM, Arrigo Marchiori  wrote:

Hello,

On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:


The best approach I believe is to add a whitelist feature as for macro
files.

Users can add then the links they wish to approve.

Do you mean file-based whitelists instead of target-based?

I will try to explain myself better: the current filter on AOO 4.1.10
is target-based, because it is the target of the link that triggers
the warning. Are you suggesting to add a whitelist based on files, for
example "allow any links in documents from this directory"?

If so, would you use the same whitelist as for macros, or would you
introduce another one?

Other ideas that come to my mind at the moment, just for the sake of
this discussion:

1- whitelist individual targets such as ".uno:Reload" and any other
``complaints'' we will received between one release and the next;

There is such a list of extensions that we are likely to trust. That list has 
not been updated in some time and one change we made was adding OpenOffice help 
files to that list. We should look into expanding the list.


2- whitelist all ".uno:" targets (but would this open possible
malicious exploits?)

We do know about a set of protocols. There were four (IIRC) openoffice specific 
ones. We chose to trust the help protocol.. .uno is another. We should think 
about trusting all four by understanding better what each do.


3- add a generic box "don't ask any more" on the warning window, that
disables _any_ future warnings;

Alternatively the code has three settings of which two cannot be selected.

1. Trust hyperlinks with a certain combination of protocol and extension.
2. Trust all hyperlinks
3. Trust no hyperlinks other than help files.

We should enable the setting of once of these three existing constants of 
hyperlink trust as a user setting.


4- add a generic box "don't ask any more" on the warning window, that
disables future warnings for the _protocol of the current link_ (for
example all http:// or ftp:// or uno: links);

5- add a generic box "don't ask any more" on the warning window, that
disables future warnings for the _target of the current link_ (for
example ".uno:Reload" or "http://server.com/document.html;);

6 - We do need to improve the dialog to better explain the risks/

All The Best,
Dave


6-  any other ideas worth discussing? 

Best regards.


On 04.05.21 16:05, k...@kshelton.plus.com wrote:

For some years I've had a Reload button in my Calc document to avoid having to 
use the File menu. Just updated to 4.1.10 and now I get a message when pressing 
Reload button:

This hyperlink is going to open “.uno:Reload”. Do you want to proceed?

Is there a way of switching off this message please?

Thanks.

Regards
Keith Shelton



--
This is the Way! http://www.apache.org/theapacheway/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org


--
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org


--
This is the Way! http://www.apache.org/theapacheway/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Peter Kovacs]

Hi Dave,

We are talking about a whitelisting feature. And the discussion tries to 
evaluate if requirements between macro and hyperlink do differ from user 
perspective

I suggest not to mix whitlisting feature with the particular security method. 
Ideal would be if the security has only the need to ask. 
Whitelist.IsAllowed(URL, )
 and that's it. 
It may be from an architectural standpoint that this might be even a property 
of the Url itself instead of the a security method. 

All the best
Peter


Am 7. Mai 2021 07:26:28 MESZ schrieb Dave Fisher :
>I think it is really important to not mix macro security with hyperlink
>security. We are discussing hyperlink security.
>
>If you look into the bugzilla and the way we fixed the recently
>disclosed CVE you will find that mixing the two was how many of these
>issues have lingered for 15 years since OpenOffice.org 2.0 in roughly
>2006.
>
>Please discuss improvements with macros elsewhere.
>
>Regards,
>Dave
>
>> On May 5, 2021, at 10:44 AM, Peter Kovacs  wrote:
>> 
>> 
>> On 05.05.21 14:37, Arrigo Marchiori wrote:
>>> Hello,
>>> 
>>> On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:
>>> 
 The best approach I believe is to add a whitelist feature as for
>macro
 files.
 
 Users can add then the links they wish to approve.
>>> Do you mean file-based whitelists instead of target-based?
>>> 
>>> I will try to explain myself better: the current filter on AOO
>4.1.10
>>> is target-based, because it is the target of the link that triggers
>>> the warning. Are you suggesting to add a whitelist based on files,
>for
>>> example "allow any links in documents from this directory"?
>>> 
>>> If so, would you use the same whitelist as for macros, or would you
>>> introduce another one?
>> 
>> I do not think that it makes sense to allow
>https://my.payload.crime/AOO_diskscrambler.ods to be seen as save
>target for opening and macro execution at the same time.
>> 
>> Better is to have both separated. And the simple practicable solution
>is to just add an own list which allows targets to be listed.
>> 
>> 
>> If we would want to have a vision, where we should develop to, this
>would be mine:
>> 
>> We have One list and 2 properties. 1 property for hyperlink
>whitelisting, the other one for (macro) execution. I like our 4
>security stages.
>> 
>> Example for a customized setup on a POSIX filesystem (security level
>3 = very high and 0 = low; first value is hyperlink, second value is
>macro execution of this origin):
>> 
>> /tmp  (3,3) => Everything in the temp folder does not open links or
>execute macros
>> 
>> ~/ (2,2) => something that is within the home path, but not a folder
>listed below, may execute signed macros or open targets that have a
>trusted certificate
>> 
>> ~/Downloads (2,3) => Downloads may open Links with a trusted
>certificate but not allow to execute any macros
>> 
>> ~/onlymystuff (0,0) => this is my documents and I allow everything
>possible here.
>> 
>> ~/macro_examples (3,1) => delivered example I do not want them to
>execute, but they may be not linked by another document.
>> 
>> ftps://securecontent.org ( 2,2) => this links pointing to this target
>are opened, and the downloaded file may execute macros if they are
>signed with a trusted key.
>> 
>> 
>> All the best
>> 
>> Peter
>> 
>> -- 
>> This is the Way! http://www.apache.org/theapacheway/index.html
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Dave Fisher]

Hi -

The discussion should proceed considering how appopen.cpp is actually coded. 
I’m writing from memory so you will need to match my description to the actual 
variables and constants

> On May 5, 2021, at 5:37 AM, Arrigo Marchiori  wrote:
> 
> Hello,
> 
> On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:
> 
>> The best approach I believe is to add a whitelist feature as for macro
>> files.
>> 
>> Users can add then the links they wish to approve.
> 
> Do you mean file-based whitelists instead of target-based?
> 
> I will try to explain myself better: the current filter on AOO 4.1.10
> is target-based, because it is the target of the link that triggers
> the warning. Are you suggesting to add a whitelist based on files, for
> example "allow any links in documents from this directory"?
> 
> If so, would you use the same whitelist as for macros, or would you
> introduce another one?
> 
> Other ideas that come to my mind at the moment, just for the sake of
> this discussion:
> 
> 1- whitelist individual targets such as ".uno:Reload" and any other
> ``complaints'' we will received between one release and the next;

There is such a list of extensions that we are likely to trust. That list has 
not been updated in some time and one change we made was adding OpenOffice help 
files to that list. We should look into expanding the list.

> 
> 2- whitelist all ".uno:" targets (but would this open possible
> malicious exploits?)

We do know about a set of protocols. There were four (IIRC) openoffice specific 
ones. We chose to trust the help protocol.. .uno is another. We should think 
about trusting all four by understanding better what each do.

> 
> 3- add a generic box "don't ask any more" on the warning window, that
> disables _any_ future warnings;

Alternatively the code has three settings of which two cannot be selected.

1. Trust hyperlinks with a certain combination of protocol and extension.
2. Trust all hyperlinks
3. Trust no hyperlinks other than help files.

We should enable the setting of once of these three existing constants of 
hyperlink trust as a user setting.

> 
> 4- add a generic box "don't ask any more" on the warning window, that
> disables future warnings for the _protocol of the current link_ (for
> example all http:// or ftp:// or uno: links);
> 
> 5- add a generic box "don't ask any more" on the warning window, that
> disables future warnings for the _target of the current link_ (for
> example ".uno:Reload" or "http://server.com/document.html;);

6 - We do need to improve the dialog to better explain the risks/

All The Best,
Dave

> 
> 6-  any other ideas worth discussing? 
> 
> Best regards.
> 
>> On 04.05.21 16:05, k...@kshelton.plus.com wrote:
>>> For some years I've had a Reload button in my Calc document to avoid having 
>>> to use the File menu. Just updated to 4.1.10 and now I get a message when 
>>> pressing Reload button:
>>> 
>>> This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
>>> 
>>> Is there a way of switching off this message please?
>>> 
>>> Thanks.
>>> 
>>> Regards
>>> Keith Shelton
>>> 
>>> 
>> -- 
>> This is the Way! http://www.apache.org/theapacheway/index.html
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> -- 
> Arrigo
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Dave Fisher]

I think it is really important to not mix macro security with hyperlink 
security. We are discussing hyperlink security.

If you look into the bugzilla and the way we fixed the recently disclosed CVE 
you will find that mixing the two was how many of these issues have lingered 
for 15 years since OpenOffice.org 2.0 in roughly 2006.

Please discuss improvements with macros elsewhere.

Regards,
Dave

> On May 5, 2021, at 10:44 AM, Peter Kovacs  wrote:
> 
> 
> On 05.05.21 14:37, Arrigo Marchiori wrote:
>> Hello,
>> 
>> On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:
>> 
>>> The best approach I believe is to add a whitelist feature as for macro
>>> files.
>>> 
>>> Users can add then the links they wish to approve.
>> Do you mean file-based whitelists instead of target-based?
>> 
>> I will try to explain myself better: the current filter on AOO 4.1.10
>> is target-based, because it is the target of the link that triggers
>> the warning. Are you suggesting to add a whitelist based on files, for
>> example "allow any links in documents from this directory"?
>> 
>> If so, would you use the same whitelist as for macros, or would you
>> introduce another one?
> 
> I do not think that it makes sense to allow 
> https://my.payload.crime/AOO_diskscrambler.ods to be seen as save target for 
> opening and macro execution at the same time.
> 
> Better is to have both separated. And the simple practicable solution is to 
> just add an own list which allows targets to be listed.
> 
> 
> If we would want to have a vision, where we should develop to, this would be 
> mine:
> 
> We have One list and 2 properties. 1 property for hyperlink whitelisting, the 
> other one for (macro) execution. I like our 4 security stages.
> 
> Example for a customized setup on a POSIX filesystem (security level 3 = very 
> high and 0 = low; first value is hyperlink, second value is macro execution 
> of this origin):
> 
> /tmp  (3,3) => Everything in the temp folder does not open links or execute 
> macros
> 
> ~/ (2,2) => something that is within the home path, but not a folder listed 
> below, may execute signed macros or open targets that have a trusted 
> certificate
> 
> ~/Downloads (2,3) => Downloads may open Links with a trusted certificate but 
> not allow to execute any macros
> 
> ~/onlymystuff (0,0) => this is my documents and I allow everything possible 
> here.
> 
> ~/macro_examples (3,1) => delivered example I do not want them to execute, 
> but they may be not linked by another document.
> 
> ftps://securecontent.org ( 2,2) => this links pointing to this target are 
> opened, and the downloaded file may execute macros if they are signed with a 
> trusted key.
> 
> 
> All the best
> 
> Peter
> 
> -- 
> This is the Way! http://www.apache.org/theapacheway/index.html
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Keith N. McKenna]

Greetings all;
Apologies for the encrypted version that went to the lists.here it is
unencrypted.
thoughts on the subject in line knmc, the other Keith in the room. ;)
On 2021-05-05 08:37, Arrigo Marchiori wrote:
> Hello,
> 
> On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:
> 
>> The best approach I believe is to add a whitelist feature as for macro
>> files.
>>
>> Users can add then the links they wish to approve.
From a strictly process standpoint. I see a major problem with a "white
list" that depends on a user manually entering data or picking from a
drop-down list or multiple check boxes. The "average user" who may well
not know what ftps or .uno:is and does is likely to go for the "all of
the above" option. Given that aim of what were a re discussing is a fix
to a security vulnerability, that would be the last thing we would want
anyone to choose.

> 
> Do you mean file-based whitelists instead of target-based?
> 
> I will try to explain myself better: the current filter on AOO 4.1.10
> is target-based, because it is the target of the link that triggers
> the warning. Are you suggesting to add a whitelist based on files, for
> example "allow any links in documents from this directory"?
> 
> If so, would you use the same whitelist as for macros, or would you
> introduce another one?
> 
> Other ideas that come to my mind at the moment, just for the sake of
> this discussion:
> 
>  1- whitelist individual targets such as ".uno:Reload" and any other
>  ``complaints'' we will received between one release and the next;

This could be a reasonable solution though I do see potential drawbacks.
1) Is dependent on
> 
>  2- whitelist all ".uno:" targets (but would this open possible
>  malicious exploits?)
> 
>  3- add a generic box "don't ask any more" on the warning window, that
>  disables _any_ future warnings;
> 
>  4- add a generic box "don't ask any more" on the warning window, that
>  disables future warnings for the _protocol of the current link_ (for
>  example all http:// or ftp:// or uno: links);
> 
>  5- add a generic box "don't ask any more" on the warning window, that
>  disables future warnings for the _target of the current link_ (for
>  example ".uno:Reload" or "http://server.com/document.html;);
> 
>  6-  any other ideas worth discussing? 
> 
> Best regards.
> 


>> On 04.05.21 16:05, k...@kshelton.plus.com wrote:
>>> For some years I've had a Reload button in my Calc document to avoid having 
>>> to use the File menu. Just updated to 4.1.10 and now I get a message when 
>>> pressing Reload button:
>>>
>>> This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
>>>
>>> Is there a way of switching off this message please?
>>>
>>> Thanks.
>>>
>>> Regards
>>> Keith Shelton
>>>
>>>
>> -- 
>> This is the Way! http://www.apache.org/theapacheway/index.html
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
> 






signature.asc
Description: OpenPGP digital signature

Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)

[Matthias Seidel]

Hi Jim,

Am 06.05.21 um 15:08 schrieb Jim Jagielski:
> Once we tag HEAD of AOO41X to AOO4110

Can't wait! ;-)

I have dozens of commits to be backported to AOO41X...

Matthias

>
>> On May 6, 2021, at 8:28 AM, Matthias Seidel  
>> wrote:
>>
>> Hi all,
>>
>> Just a pragmatic question:
>>
>> When do we want to start working on AOO 4.1.11?
>>
>> The sooner we branch it, the sooner we can do Test builds and let people
>> see if their problem is fixed...
>>
>> Matthias
>>
>> Am 05.05.21 um 23:31 schrieb Peter Kovacs:
>>> On 05.05.21 22:11, Arrigo Marchiori wrote:
 Hello Peter, all,

 On Wed, May 05, 2021 at 05:44:17PM +, Peter Kovacs wrote:

> On 05.05.21 14:37, Arrigo Marchiori wrote:
>> Hello,
>>
>> On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:
>>
>>> The best approach I believe is to add a whitelist feature as for
>>> macro
>>> files.
>>>
>>> Users can add then the links they wish to approve.
>> Do you mean file-based whitelists instead of target-based?
>>
>> I will try to explain myself better: the current filter on AOO 4.1.10
>> is target-based, because it is the target of the link that triggers
>> the warning. Are you suggesting to add a whitelist based on files, for
>> example "allow any links in documents from this directory"?
>>
>> If so, would you use the same whitelist as for macros, or would you
>> introduce another one?
> I do not think that it makes sense to allow
> https://my.payload.crime/AOO_diskscrambler.ods to be seen as save
> target for
> opening and macro execution at the same time.
>
> Better is to have both separated. And the simple practicable
> solution is to
> just add an own list which allows targets to be listed.
 I see.  But please let us distinguish targets and sources.
>>> Well, yea this is a nice abstraction I did not make. Good one.
 The macros' whitelist contains _directories_ (I don't really like
 calling them folders, I hope you don't mind) whose files are trusted,
 with respect to macro execution.
>>> sure. Names are sound and smoke ;) - sorry can not resist this german
>>> IT idiom.
 In your reply above you seem to discuss a whitelist of _link targets_?
 Not documents, containing links that shall always be followed?
>>> Yes, I thought on the target of the link. For me was this the
>>> important trait.
>>>
>>> However if I think in which document I grant the security level. Hmm,
>>> I think this makes the whole concept a lot easier.
>>>
>>> Plus we would then one list. So we extend an existing feature.
>>>
> If we would want to have a vision, where we should develop to, this
> would be
> mine:
>
> We have One list and 2 properties. 1 property for hyperlink
> whitelisting,
> the other one for (macro) execution. I like our 4 security stages.
 The four security levels currently available for macros, if I
 understand correctly, are based on a combination of:

   - digital signatures of the macros (signed or not),
   - trust of certain digital signatures (certificate trusted or not),
   - position of the document (directory whitelisted or not).

 This is... quite complex IMHO.
>>> That why I have written it is maybe a vision. And maybe it is to much.
 Did you refer exactly to this model?
>>> yes kind of. I thought that a hyperlink has some sort of certiicate
>>> and an macro can have some certification and that is kind of the same
>>> thing...
 Or
 shall we rather adopt a simpler one for links, for example only
 considering the directories whitelist?
>>> Now that I think on your approach I think we should only look at the
>>> directory that the document has been opened from. But still I would
>>> still rather configure it per directory, then in a general and work
>>> with exclusions.
>>>
>>> However this is maybe not so smart to implement now, since our profile
>>> is not robust enough. It will break eventually, and then all nice
>>> settings are lost. And that is not something I would like to have.
>>>
 And to understand better: does AOO allow to sign individual macros? Or
 just the document containing them? I don't think that it allows to
 sign individual links within a document.
>>> No it would not sign individual links on the document.- But don't we
>>> have document signing?
>>>
>>> For links we could check if the document is signed.
>>>
>>>
>>> So summing up:
>>>
>>> # Instead of checking where the hyperlink is refering to, only check
>>> where the document has been stored. (Treat hyperlinks as macros so to
>>> say.)
>>>
>>> # As an enhancement we could add a model that checks for the nearest
>>> applicable path to the document, and applies that rule.
>>>
> Example for a customized setup on a POSIX filesystem (security level
> 3 =
> very high and 0 = low; first value is hyperlink, second value is macro
> 

Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)

[Jim Jagielski]

Once we tag HEAD of AOO41X to AOO4110

> On May 6, 2021, at 8:28 AM, Matthias Seidel  
> wrote:
> 
> Hi all,
> 
> Just a pragmatic question:
> 
> When do we want to start working on AOO 4.1.11?
> 
> The sooner we branch it, the sooner we can do Test builds and let people
> see if their problem is fixed...
> 
> Matthias
> 
> Am 05.05.21 um 23:31 schrieb Peter Kovacs:
>> 
>> On 05.05.21 22:11, Arrigo Marchiori wrote:
>>> Hello Peter, all,
>>> 
>>> On Wed, May 05, 2021 at 05:44:17PM +, Peter Kovacs wrote:
>>> 
 On 05.05.21 14:37, Arrigo Marchiori wrote:
> Hello,
> 
> On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:
> 
>> The best approach I believe is to add a whitelist feature as for
>> macro
>> files.
>> 
>> Users can add then the links they wish to approve.
> Do you mean file-based whitelists instead of target-based?
> 
> I will try to explain myself better: the current filter on AOO 4.1.10
> is target-based, because it is the target of the link that triggers
> the warning. Are you suggesting to add a whitelist based on files, for
> example "allow any links in documents from this directory"?
> 
> If so, would you use the same whitelist as for macros, or would you
> introduce another one?
 I do not think that it makes sense to allow
 https://my.payload.crime/AOO_diskscrambler.ods to be seen as save
 target for
 opening and macro execution at the same time.
 
 Better is to have both separated. And the simple practicable
 solution is to
 just add an own list which allows targets to be listed.
>>> I see.  But please let us distinguish targets and sources.
>> Well, yea this is a nice abstraction I did not make. Good one.
>>> The macros' whitelist contains _directories_ (I don't really like
>>> calling them folders, I hope you don't mind) whose files are trusted,
>>> with respect to macro execution.
>> sure. Names are sound and smoke ;) - sorry can not resist this german
>> IT idiom.
>>> In your reply above you seem to discuss a whitelist of _link targets_?
>>> Not documents, containing links that shall always be followed?
>> 
>> Yes, I thought on the target of the link. For me was this the
>> important trait.
>> 
>> However if I think in which document I grant the security level. Hmm,
>> I think this makes the whole concept a lot easier.
>> 
>> Plus we would then one list. So we extend an existing feature.
>> 
 If we would want to have a vision, where we should develop to, this
 would be
 mine:
 
 We have One list and 2 properties. 1 property for hyperlink
 whitelisting,
 the other one for (macro) execution. I like our 4 security stages.
>>> The four security levels currently available for macros, if I
>>> understand correctly, are based on a combination of:
>>> 
>>>   - digital signatures of the macros (signed or not),
>>>   - trust of certain digital signatures (certificate trusted or not),
>>>   - position of the document (directory whitelisted or not).
>>> 
>>> This is... quite complex IMHO.
>> That why I have written it is maybe a vision. And maybe it is to much.
>>> Did you refer exactly to this model?
>> yes kind of. I thought that a hyperlink has some sort of certiicate
>> and an macro can have some certification and that is kind of the same
>> thing...
>>> Or
>>> shall we rather adopt a simpler one for links, for example only
>>> considering the directories whitelist?
>> 
>> Now that I think on your approach I think we should only look at the
>> directory that the document has been opened from. But still I would
>> still rather configure it per directory, then in a general and work
>> with exclusions.
>> 
>> However this is maybe not so smart to implement now, since our profile
>> is not robust enough. It will break eventually, and then all nice
>> settings are lost. And that is not something I would like to have.
>> 
>>> 
>>> And to understand better: does AOO allow to sign individual macros? Or
>>> just the document containing them? I don't think that it allows to
>>> sign individual links within a document.
>> 
>> No it would not sign individual links on the document.- But don't we
>> have document signing?
>> 
>> For links we could check if the document is signed.
>> 
>> 
>> So summing up:
>> 
>> # Instead of checking where the hyperlink is refering to, only check
>> where the document has been stored. (Treat hyperlinks as macros so to
>> say.)
>> 
>> # As an enhancement we could add a model that checks for the nearest
>> applicable path to the document, and applies that rule.
>> 
>>> 
 Example for a customized setup on a POSIX filesystem (security level
 3 =
 very high and 0 = low; first value is hyperlink, second value is macro
 execution of this origin):
 
 /tmp  (3,3) => Everything in the temp folder does not open links or
 execute
 macros
 
 ~/ (2,2) => something that is within the home path, but not a 

Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)

[Matthias Seidel]

Hi all,

Just a pragmatic question:

When do we want to start working on AOO 4.1.11?

The sooner we branch it, the sooner we can do Test builds and let people
see if their problem is fixed...

Matthias

Am 05.05.21 um 23:31 schrieb Peter Kovacs:
>
> On 05.05.21 22:11, Arrigo Marchiori wrote:
>> Hello Peter, all,
>>
>> On Wed, May 05, 2021 at 05:44:17PM +, Peter Kovacs wrote:
>>
>>> On 05.05.21 14:37, Arrigo Marchiori wrote:
 Hello,

 On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:

> The best approach I believe is to add a whitelist feature as for
> macro
> files.
>
> Users can add then the links they wish to approve.
 Do you mean file-based whitelists instead of target-based?

 I will try to explain myself better: the current filter on AOO 4.1.10
 is target-based, because it is the target of the link that triggers
 the warning. Are you suggesting to add a whitelist based on files, for
 example "allow any links in documents from this directory"?

 If so, would you use the same whitelist as for macros, or would you
 introduce another one?
>>> I do not think that it makes sense to allow
>>> https://my.payload.crime/AOO_diskscrambler.ods to be seen as save
>>> target for
>>> opening and macro execution at the same time.
>>>
>>> Better is to have both separated. And the simple practicable
>>> solution is to
>>> just add an own list which allows targets to be listed.
>> I see.  But please let us distinguish targets and sources.
> Well, yea this is a nice abstraction I did not make. Good one.
>> The macros' whitelist contains _directories_ (I don't really like
>> calling them folders, I hope you don't mind) whose files are trusted,
>> with respect to macro execution.
> sure. Names are sound and smoke ;) - sorry can not resist this german
> IT idiom.
>> In your reply above you seem to discuss a whitelist of _link targets_?
>> Not documents, containing links that shall always be followed?
>
> Yes, I thought on the target of the link. For me was this the
> important trait.
>
> However if I think in which document I grant the security level. Hmm,
> I think this makes the whole concept a lot easier.
>
> Plus we would then one list. So we extend an existing feature.
>
>>> If we would want to have a vision, where we should develop to, this
>>> would be
>>> mine:
>>>
>>> We have One list and 2 properties. 1 property for hyperlink
>>> whitelisting,
>>> the other one for (macro) execution. I like our 4 security stages.
>> The four security levels currently available for macros, if I
>> understand correctly, are based on a combination of:
>>
>>   - digital signatures of the macros (signed or not),
>>   - trust of certain digital signatures (certificate trusted or not),
>>   - position of the document (directory whitelisted or not).
>>
>> This is... quite complex IMHO.
> That why I have written it is maybe a vision. And maybe it is to much.
>> Did you refer exactly to this model?
> yes kind of. I thought that a hyperlink has some sort of certiicate
> and an macro can have some certification and that is kind of the same
> thing...
>> Or
>> shall we rather adopt a simpler one for links, for example only
>> considering the directories whitelist?
>
> Now that I think on your approach I think we should only look at the
> directory that the document has been opened from. But still I would
> still rather configure it per directory, then in a general and work
> with exclusions.
>
> However this is maybe not so smart to implement now, since our profile
> is not robust enough. It will break eventually, and then all nice
> settings are lost. And that is not something I would like to have.
>
>>
>> And to understand better: does AOO allow to sign individual macros? Or
>> just the document containing them? I don't think that it allows to
>> sign individual links within a document.
>
> No it would not sign individual links on the document.- But don't we
> have document signing?
>
> For links we could check if the document is signed.
>
>
> So summing up:
>
> # Instead of checking where the hyperlink is refering to, only check
> where the document has been stored. (Treat hyperlinks as macros so to
> say.)
>
> # As an enhancement we could add a model that checks for the nearest
> applicable path to the document, and applies that rule.
>
>>
>>> Example for a customized setup on a POSIX filesystem (security level
>>> 3 =
>>> very high and 0 = low; first value is hyperlink, second value is macro
>>> execution of this origin):
>>>
>>> /tmp  (3,3) => Everything in the temp folder does not open links or
>>> execute
>>> macros
>>>
>>> ~/ (2,2) => something that is within the home path, but not a folder
>>> listed
>>> below, may execute signed macros or open targets that have a trusted
>>> certificate
>>>
>>> ~/Downloads (2,3) => Downloads may open Links with a trusted
>>> certificate but
>>> not allow to execute any macros
>>>
>>> ~/onlymystuff (0,0) => this 

Re: Hyperlink Warning Message

[Peter Kovacs]

On 05.05.21 22:11, Arrigo Marchiori wrote:

Hello Peter, all,

On Wed, May 05, 2021 at 05:44:17PM +, Peter Kovacs wrote:


On 05.05.21 14:37, Arrigo Marchiori wrote:

Hello,

On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:


The best approach I believe is to add a whitelist feature as for macro
files.

Users can add then the links they wish to approve.

Do you mean file-based whitelists instead of target-based?

I will try to explain myself better: the current filter on AOO 4.1.10
is target-based, because it is the target of the link that triggers
the warning. Are you suggesting to add a whitelist based on files, for
example "allow any links in documents from this directory"?

If so, would you use the same whitelist as for macros, or would you
introduce another one?

I do not think that it makes sense to allow
https://my.payload.crime/AOO_diskscrambler.ods to be seen as save target for
opening and macro execution at the same time.

Better is to have both separated. And the simple practicable solution is to
just add an own list which allows targets to be listed.

I see.  But please let us distinguish targets and sources.

Well, yea this is a nice abstraction I did not make. Good one.

The macros' whitelist contains _directories_ (I don't really like
calling them folders, I hope you don't mind) whose files are trusted,
with respect to macro execution.
sure. Names are sound and smoke ;) - sorry can not resist this german IT 
idiom.

In your reply above you seem to discuss a whitelist of _link targets_?
Not documents, containing links that shall always be followed?


Yes, I thought on the target of the link. For me was this the important 
trait.


However if I think in which document I grant the security level. Hmm, I 
think this makes the whole concept a lot easier.


Plus we would then one list. So we extend an existing feature.


If we would want to have a vision, where we should develop to, this would be
mine:

We have One list and 2 properties. 1 property for hyperlink whitelisting,
the other one for (macro) execution. I like our 4 security stages.

The four security levels currently available for macros, if I
understand correctly, are based on a combination of:

  - digital signatures of the macros (signed or not),
  - trust of certain digital signatures (certificate trusted or not),
  - position of the document (directory whitelisted or not).

This is... quite complex IMHO.

That why I have written it is maybe a vision. And maybe it is to much.

Did you refer exactly to this model?
yes kind of. I thought that a hyperlink has some sort of certiicate and 
an macro can have some certification and that is kind of the same thing...

Or
shall we rather adopt a simpler one for links, for example only
considering the directories whitelist?


Now that I think on your approach I think we should only look at the 
directory that the document has been opened from. But still I would 
still rather configure it per directory, then in a general and work with 
exclusions.


However this is maybe not so smart to implement now, since our profile 
is not robust enough. It will break eventually, and then all nice 
settings are lost. And that is not something I would like to have.




And to understand better: does AOO allow to sign individual macros? Or
just the document containing them? I don't think that it allows to
sign individual links within a document.


No it would not sign individual links on the document.- But don't we 
have document signing?


For links we could check if the document is signed.


So summing up:

# Instead of checking where the hyperlink is refering to, only check 
where the document has been stored. (Treat hyperlinks as macros so to say.)


# As an enhancement we could add a model that checks for the nearest 
applicable path to the document, and applies that rule.





Example for a customized setup on a POSIX filesystem (security level 3 =
very high and 0 = low; first value is hyperlink, second value is macro
execution of this origin):

/tmp  (3,3) => Everything in the temp folder does not open links or execute
macros

~/ (2,2) => something that is within the home path, but not a folder listed
below, may execute signed macros or open targets that have a trusted
certificate

~/Downloads (2,3) => Downloads may open Links with a trusted certificate but
not allow to execute any macros

~/onlymystuff (0,0) => this is my documents and I allow everything possible
here.

~/macro_examples (3,1) => delivered example I do not want them to execute,
but they may be not linked by another document.

ftps://securecontent.org ( 2,2) => this links pointing to this target are
opened, and the downloaded file may execute macros if they are signed with a
trusted key.

--
This is the Way! http://www.apache.org/theapacheway/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: 

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Hello Peter, all,

On Wed, May 05, 2021 at 05:44:17PM +, Peter Kovacs wrote:

> On 05.05.21 14:37, Arrigo Marchiori wrote:
> > Hello,
> > 
> > On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:
> > 
> > > The best approach I believe is to add a whitelist feature as for macro
> > > files.
> > > 
> > > Users can add then the links they wish to approve.
> > Do you mean file-based whitelists instead of target-based?
> > 
> > I will try to explain myself better: the current filter on AOO 4.1.10
> > is target-based, because it is the target of the link that triggers
> > the warning. Are you suggesting to add a whitelist based on files, for
> > example "allow any links in documents from this directory"?
> > 
> > If so, would you use the same whitelist as for macros, or would you
> > introduce another one?
> 
> I do not think that it makes sense to allow
> https://my.payload.crime/AOO_diskscrambler.ods to be seen as save target for
> opening and macro execution at the same time.
> 
> Better is to have both separated. And the simple practicable solution is to
> just add an own list which allows targets to be listed.

I see.  But please let us distinguish targets and sources.

The macros' whitelist contains _directories_ (I don't really like
calling them folders, I hope you don't mind) whose files are trusted,
with respect to macro execution.

In your reply above you seem to discuss a whitelist of _link targets_?
Not documents, containing links that shall always be followed?

> If we would want to have a vision, where we should develop to, this would be
> mine:
> 
> We have One list and 2 properties. 1 property for hyperlink whitelisting,
> the other one for (macro) execution. I like our 4 security stages.

The four security levels currently available for macros, if I
understand correctly, are based on a combination of:

 - digital signatures of the macros (signed or not),
 - trust of certain digital signatures (certificate trusted or not),
 - position of the document (directory whitelisted or not).

This is... quite complex IMHO. Did you refer exactly to this model? Or
shall we rather adopt a simpler one for links, for example only
considering the directories whitelist?

And to understand better: does AOO allow to sign individual macros? Or
just the document containing them? I don't think that it allows to
sign individual links within a document.

> Example for a customized setup on a POSIX filesystem (security level 3 =
> very high and 0 = low; first value is hyperlink, second value is macro
> execution of this origin):
> 
> /tmp  (3,3) => Everything in the temp folder does not open links or execute
> macros
> 
> ~/ (2,2) => something that is within the home path, but not a folder listed
> below, may execute signed macros or open targets that have a trusted
> certificate
> 
> ~/Downloads (2,3) => Downloads may open Links with a trusted certificate but
> not allow to execute any macros
> 
> ~/onlymystuff (0,0) => this is my documents and I allow everything possible
> here.
> 
> ~/macro_examples (3,1) => delivered example I do not want them to execute,
> but they may be not linked by another document.
> 
> ftps://securecontent.org ( 2,2) => this links pointing to this target are
> opened, and the downloaded file may execute macros if they are signed with a
> trusted key.

-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Marcus]

Am 05.05.21 um 14:37 schrieb Arrigo Marchiori:

On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:


The best approach I believe is to add a whitelist feature as for macro
files.

Users can add then the links they wish to approve.


Do you mean file-based whitelists instead of target-based?

I will try to explain myself better: the current filter on AOO 4.1.10
is target-based, because it is the target of the link that triggers
the warning. Are you suggesting to add a whitelist based on files, for
example "allow any links in documents from this directory"?

If so, would you use the same whitelist as for macros, or would you
introduce another one?

Other ideas that come to my mind at the moment, just for the sake of
this discussion:

  1- whitelist individual targets such as ".uno:Reload" and any other
  ``complaints'' we will received between one release and the next;

  2- whitelist all ".uno:" targets (but would this open possible
  malicious exploits?)

  3- add a generic box "don't ask any more" on the warning window, that
  disables _any_ future warnings;

  4- add a generic box "don't ask any more" on the warning window, that
  disables future warnings for the _protocol of the current link_ (for
  example all http:// or ftp:// or uno: links);

  5- add a generic box "don't ask any more" on the warning window, that
  disables future warnings for the _target of the current link_ (for
  example ".uno:Reload" or "http://server.com/document.html;);

  6-  any other ideas worth discussing? 


A comination of the whitelist (number 1) and a generic box "don't ask 
any more" on the warning window, that disables future warnings as long 
as AOO is open. So, user is able to get a reminder with a new session / 
start of AOO.


We shouldn't do point 3 - 5. IMHO this is against the security level we 
want to reach. The user can do this and on the next day it's forgotten 
and cannot be reverted.


I don't know how complex this is as saving the also configuration is a 
point I don't know how it is done. So, it's just a wish what could be 
best for the users.


My 2 ct.

Marcus


On 04.05.21 16:05, k...@kshelton.plus.com wrote:

For some years I've had a Reload button in my Calc document to avoid having to 
use the File menu. Just updated to 4.1.10 and now I get a message when pressing 
Reload button:

This hyperlink is going to open “.uno:Reload”. Do you want to proceed?

Is there a way of switching off this message please?



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Hyperlink Warning Message

[Arrigo Marchiori]

Hello,

On Wed, May 05, 2021 at 07:08:11AM +, Peter Kovacs wrote:

> The best approach I believe is to add a whitelist feature as for macro
> files.
> 
> Users can add then the links they wish to approve.

Do you mean file-based whitelists instead of target-based?

I will try to explain myself better: the current filter on AOO 4.1.10
is target-based, because it is the target of the link that triggers
the warning. Are you suggesting to add a whitelist based on files, for
example "allow any links in documents from this directory"?

If so, would you use the same whitelist as for macros, or would you
introduce another one?

Other ideas that come to my mind at the moment, just for the sake of
this discussion:

 1- whitelist individual targets such as ".uno:Reload" and any other
 ``complaints'' we will received between one release and the next;

 2- whitelist all ".uno:" targets (but would this open possible
 malicious exploits?)

 3- add a generic box "don't ask any more" on the warning window, that
 disables _any_ future warnings;

 4- add a generic box "don't ask any more" on the warning window, that
 disables future warnings for the _protocol of the current link_ (for
 example all http:// or ftp:// or uno: links);

 5- add a generic box "don't ask any more" on the warning window, that
 disables future warnings for the _target of the current link_ (for
 example ".uno:Reload" or "http://server.com/document.html;);

 6-  any other ideas worth discussing? 

Best regards.

> On 04.05.21 16:05, k...@kshelton.plus.com wrote:
> > For some years I've had a Reload button in my Calc document to avoid having 
> > to use the File menu. Just updated to 4.1.10 and now I get a message when 
> > pressing Reload button:
> > 
> > This hyperlink is going to open “.uno:Reload”. Do you want to proceed?
> > 
> > Is there a way of switching off this message please?
> > 
> > Thanks.
> > 
> > Regards
> > Keith Shelton
> > 
> > 
> -- 
> This is the Way! http://www.apache.org/theapacheway/index.html
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org