Done > On May 11, 2021, at 1:53 PM, Jim Jagielski <j...@jagunet.com> wrote: > > 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 >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
