Hi Jim, 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... Matthias > >> 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 > >
smime.p7s
Description: S/MIME Cryptographic Signature
