Once we tag HEAD of AOO41X to AOO4110 > 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
