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
