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 /.
>> Fo
