Thanks! Am 11.05.21 um 20:04 schrieb Jim Jagielski: > 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 > >
smime.p7s
Description: S/MIME Cryptographic Signature
