Will do... 

> On May 10, 2021, at 2:49 PM, Marcus <marcus.m...@wtnet.de> 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 <matthias.sei...@hamburg.de> 
>>>> 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 +0000, Peter Kovacs wrote:
>>>>>>> On 05.05.21 14: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.
>>>>>>>> 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.
> ---------------------------------------------------------------------
> 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

Reply via email to