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 /. >> 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
