You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Matthias Seidel <ma...@hamburg.de> on 2021/05/06 12:28:54 UTC
Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
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.
Re: Start working on AOO 4.1.11?
Posted by Matthias Seidel <ma...@hamburg.de>.
Hi Pedro,
Am 27.05.21 um 14:45 schrieb Pedro Lino:
> Hi again
>
>> On 05/27/2021 1:39 PM Matthias Seidel <ma...@hamburg.de> 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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: Start working on AOO 4.1.11?
Posted by Pedro Lino <pe...@mailbox.org.INVALID>.
Hi again
> On 05/27/2021 1:39 PM Matthias Seidel <ma...@hamburg.de> 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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Posted by Matthias Seidel <ma...@hamburg.de>.
Hi Pedro,
Am 27.05.21 um 14:31 schrieb Pedro Lino:
> Hi Matthias
>
>> On 05/27/2021 1:19 PM Matthias Seidel <ma...@hamburg.de> 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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: Start working on AOO 4.1.11?
Posted by Pedro Lino <pe...@mailbox.org.INVALID>.
Hi Matthias
> On 05/27/2021 1:19 PM Matthias Seidel <ma...@hamburg.de> 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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Posted by Matthias Seidel <ma...@hamburg.de>.
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,
Re: Start working on AOO 4.1.11?
Posted by Matthias Seidel <ma...@hamburg.de>.
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,
Re: Start working on AOO 4.1.11?
Posted by Marcus <ma...@wtnet.de>.
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.
installs good, with a valid signature (special build from Matthias) now
also without the big warning from Windows. Looks promising for future
builds.
And still with the warning message for bad hyperlinks. ;-)
Marcus
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Posted by Matthias Seidel <ma...@hamburg.de>.
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,
Re: Start working on AOO 4.1.11?
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
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,
--
Arrigo
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Posted by Marcus <ma...@wtnet.de>.
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: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Posted by Marcus <ma...@wtnet.de>.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
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: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Posted by Matthias Seidel <ma...@hamburg.de>.
Thanks!
Am 11.05.21 um 20:04 schrieb Jim Jagielski:
> Done
>
>> On May 11, 2021, at 1:53 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>> Will do...
>>
>>> On May 10, 2021, at 2:49 PM, Marcus <ma...@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 <ma...@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-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Done
> On May 11, 2021, at 1:53 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> Will do...
>
>> On May 10, 2021, at 2:49 PM, Marcus <ma...@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 <ma...@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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Will do...
> On May 10, 2021, at 2:49 PM, Marcus <ma...@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 <ma...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Posted by Matthias Seidel <ma...@hamburg.de>.
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
>>>> <ma...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Posted by Marcus <ma...@wtnet.de>.
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 <ma...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Posted by Matthias Seidel <ma...@hamburg.de>.
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 <ma...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Start working on AOO 4.1.11? (was: Re: Hyperlink Warning Message)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Once we tag HEAD of AOO41X to AOO4110
> On May 6, 2021, at 8:28 AM, Matthias Seidel <ma...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org