Greetings all; My thoughts and opinions on this subject are solely based on my 20+ years in the field of Process Engineering, as I have very limited experience with writing or designing code. My thoughts on the subject will be expressed in line. regards, 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 +0000, 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 users taking the time to give constructive
feedback.
a)Conversely,it could generate serious aggravation from
non-technical users generating a fair amount of
bad publicity not only in the lists and the forum,
but also in social media and word of mouth.
2) Could be a reasonable first step until a more automated
approach can be explored.
>
> 2- whitelist all ".uno:" targets (but would this open possible
> malicious exploits?)
This could be an excellent solution. The one caveat is that it should be
well researched so that we do do not again fall into the trap of UC
(Unintended Consequences].This is in no way intended as criticism of the
excellent work that went into solving this security problem and getting
the Release out in a timely manner. The UC trap is always waiting to
ambush anybody in any walk of life.
>
> 3- add a generic box "don't ask any more" on the warning window, that
> disables _any_ future warnings;
Again I believe that this could cause problems for the non-technical
user getting frustrated and using it, thus negating the reason for the
check. .
>
> 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
