Re: Start working on AOO 4.1.11?
Hi Pedro, Am 27.05.21 um 14:45 schrieb Pedro Lino: > Hi again > >> On 05/27/2021 1:39 PM Matthias Seidel wrote: >>> I am on Linux. Is it possible to build a binary from that branch? >> Not for me. I am already spending too much time on it. ;-) > I didn't mean for you to build on Linux :) > > I meant is there a way that I have access to the branch source or if it would > work if you simply sent me a compressed file of the openoffice source folder? Why not use branch AOO41X on GitHub? ;-) https://github.com/apache/openoffice/tree/AOO41X If you don't want to use git, you can download the source as ZIP. Regards, Matthias > > Regards, > Pedro > > - > 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
Re: Start working on AOO 4.1.11?
Hi again > On 05/27/2021 1:39 PM Matthias Seidel wrote: > > I am on Linux. Is it possible to build a binary from that branch? > > Not for me. I am already spending too much time on it. ;-) I didn't mean for you to build on Linux :) I meant is there a way that I have access to the branch source or if it would work if you simply sent me a compressed file of the openoffice source folder? Regards, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Hi Pedro, Am 27.05.21 um 14:31 schrieb Pedro Lino: > Hi Matthias > >> On 05/27/2021 1:19 PM Matthias Seidel wrote: >> Next set of Windows builds: >> >> https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/ >> >> Maybe you can spot the differences... ;-) > I am on Linux. Is it possible to build a binary from that branch? Not for me. I am already spending too much time on it. ;-) Regards, Matthias > > Regards, > Pedro > > - > 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
Re: Start working on AOO 4.1.11?
Hi Matthias > On 05/27/2021 1:19 PM Matthias Seidel wrote: > Next set of Windows builds: > > https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/ > > Maybe you can spot the differences... ;-) I am on Linux. Is it possible to build a binary from that branch? Regards, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Hi all, Next set of Windows builds: https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/ Maybe you can spot the differences... ;-) Regards, Matthias Am 14.05.21 um 17:44 schrieb Matthias Seidel: > BTW, I have first Test builds for Windows available: > > https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/ > > Nothing spectacular, but builds without problems. > > Regards, > > Matthias > > Am 14.05.21 um 07:14 schrieb Arrigo Marchiori: >> On Thu, May 13, 2021 at 09:06:32AM +0200, Marcus wrote: >> >>> Am 13.05.21 um 07:50 schrieb Arrigo Marchiori: can someone please allow setting '4.1.11' as 'Target Milestone' on BugZilla? I would like to set it on https://bz.apache.org/ooo/show_bug.cgi?id=128453 >>> done >> Thank you, Marcus! >> >> Best regards, smime.p7s Description: S/MIME Cryptographic Signature
Re: Start working on AOO 4.1.11?
Am 13.05.21 um 07:50 schrieb Arrigo Marchiori: can someone please allow setting '4.1.11' as 'Target Milestone' on BugZilla? I would like to set it on https://bz.apache.org/ooo/show_bug.cgi?id=128453 done marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Dear All, can someone please allow setting '4.1.11' as 'Target Milestone' on BugZilla? I would like to set it on https://bz.apache.org/ooo/show_bug.cgi?id=128453 Thank you in advance and best regards, -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Thanks! Am 11.05.21 um 20:04 schrieb Jim Jagielski: > Done > >> On May 11, 2021, at 1:53 PM, Jim Jagielski wrote: >> >> Will do... >> >>> On May 10, 2021, at 2:49 PM, Marcus 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 >> 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 +, Peter Kovacs wrote: > On 05.05.21 14:37, Arrigo Marchiori wrote: >> Hello, >> >> On Wed, May 05, 2021 at 07:08:11AM +, 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
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Done > On May 11, 2021, at 1:53 PM, Jim Jagielski wrote: > > Will do... > >> On May 10, 2021, at 2:49 PM, Marcus 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 > 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 +, Peter Kovacs wrote: >>> On 05.05.21 14:37, Arrigo Marchiori wrote: > Hello, > > On Wed, May 05, 2021 at 07:08:11AM +, 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.
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Will do... > On May 10, 2021, at 2:49 PM, Marcus 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 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 +, Peter Kovacs wrote: >> >>> On 05.05.21 14:37, Arrigo Marchiori wrote: Hello, On Wed, May 05, 2021 at 07:08:11AM +, 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. > >
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Am 10.05.21 um 20:49 schrieb Marcus: > 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. +1 Can we move on? Matthias > > Thanksa > > Marcus > > > On May 6, 2021, at 8:28 AM, Matthias Seidel 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 +, Peter Kovacs wrote: >> >>> On 05.05.21 14:37, Arrigo Marchiori wrote: Hello, On Wed, May 05, 2021 at 07:08:11AM +, 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? >
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
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 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 +, Peter Kovacs wrote: On 05.05.21 14:37, Arrigo Marchiori wrote: Hello, On Wed, May 05, 2021 at 07:08:11AM +, 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
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
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 >> 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 +, Peter Kovacs wrote: > On 05.05.21 14:37, Arrigo Marchiori wrote: >> Hello, >> >> On Wed, May 05, 2021 at 07:08:11AM +, 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 >
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Once we tag HEAD of AOO41X to AOO4110 > On May 6, 2021, at 8:28 AM, Matthias Seidel > 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 +, Peter Kovacs wrote: >>> On 05.05.21 14:37, Arrigo Marchiori wrote: > Hello, > > On Wed, May 05, 2021 at 07:08:11AM +, 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
