You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Eike Rathke <oo...@erack.de> on 2011/08/01 20:04:43 UTC
Re: Population of ooo-security
Hi Rob,
On Saturday, 2011-07-30 17:41:28 -0400, Rob Weir wrote:
> > Regarding Apache OpenOffice.org, LibreOffice, Symphony, RedOffice,
> > NeoOffice, BrOffice, EuroOffice, etc. as siblings that share similar
> > code in their genes from the ancestor OpenOffice.org, this approach has
> > a shortcoming in collaboration.
>
> The purpose of ooo-security is security. Any other concerns,
> including collaboration with other projects, or even including
> collaboration within this project, are secondary.
I was referring collaboration on security, for the benefit of all.
> > Given that usually users / developers / security experts report
> > a problem to _their_ project's security team, this setup would mean
> > a one-way communication if that project decided to inform AOOo, actually
> > being a pre-notification in that direction. What is that project
> > expected to do from that point on? Wait until AOOo publishes the
> > disclosure and fix? I think the project would develop its own fix and,
> > hopefully, share it with AOOo (which would involve a CLA or a permissive
> > license or a grant) and also with other siblings.
> >
>
> We've already discussed and generally agreed that we can pre-notify
> other related projects about vulnerabilities and fixes. But
> pre-notification is not the same as saying that the other projects
> must be signed up to on ooo-security.
Well, my example was about pre-notification in the other direction, from
siblings to AOOo.
> > Now if siblings develop fixes independently because AOOo security runs
> > as a strict Apache closed coterie, we may get into the situation where
> > fixes are developed in parallel, maybe with different solutions or even
> > contradictory. I think the best would be if efforts would be bundled
> > instead and the best of all possible solutions shared as
> > pre-notification with siblings.
> >
>
> There is nothing wrong with pre-notification. That was my step #3 above.
>
> Your example seems to be assuming that a single reporter reports the
> same flaw to OpenOffice, LibreOffice, Symphony, etc., independently,
No, my example was assuming that a single reporter reports only to one
project, which I think is the usual case. Further assumption was that
project would decide to pre-notify AOOo, knowing the same code is
affected.
> and that these projects develop patches independently. I suspect that
> this occurrence is quite rare. But I don't see that harm if it does
> happen. The fact is these projects are not sharing code today,
> period.
Au contraire, you're right the projects aren't sharing code, in that
case a fix and update would be sufficient, but most projects still use
the same if not identical code in areas where security issues may be
discovered.
> This is not just a statement about security. If we want to
> improve that situation with security specifically then we have two
> easy ways forward:
>
> 1) Develop the patches at Apache under a license that allows all other
> products to use it
>
> 2) Have security experts from LibreOffice developers join as Apache
> committers so they can then join the ooo-security list and contribute
> directly there.
An ideal situation I support. And btw, I wasn't talking of only
LibreOffice..
> > The problem here seems to be the perceived requirement that the Apache
> > governance would allow only PMC members on a project's security list.
> > However, I didn't see that requirement, or it's not available somewhere
> > under http://apache.org/security/
> >
> > Additionally http://apache.org/security/committers.html states that
> >
> > | Information may be shared with domain experts (eg colleagues at your
> > | employer) at the discretion of the project's security team providing
> > | that it is made clear that the information is not for public disclosure
> > | and that security@apache.org or the project's security mailing list must
> > | be copied on any communication regarding the vulnerability.
> >
> > This IMHO allows also to have selected members of sibling projects as
> > domain experts on the security list, if I interpret "at the discretion
> > of the project's security team" correctly.
> >
>
> There is nothing there that talks about having these domain experts be
> list members. In fact, it specifically talks about "copying"
> security@apache.org. That would not be necessary if the domain
> experts were security list members, since all list project security
> traffic is copied automatically to security.apache.org as well. Thus
> the information sharing implied here is through means other than
> subscription to the list.
To me it only sounds like that for any communication regarding the
vulnerability the project's (or apache) security list must be copied, so
information is shared when the domain expert communicates with a list
member and even if he consults another colleague. Of course the language
implies that the domain expert is not a list member, but "at the
discretion of the security team" is a degree of freedom to decide whom
to copy when, and if the team decides to get another expert on board on
a regular basis that's just fine.
> Also, if all traffic were automatically
> copied to 3rd party domain experts via their subscription to the list,
> then there would be zero discretion being exercised.
Given that only a hand full of known, respected and trusted persons
would be invited I don't see much difference whether they are Apache
committers or not, provided that the patches developed will be
contributed under AL2.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
RE: Population of ooo-security
Posted by "Dennis E. Hamilton" <or...@apache.org>.
+1, and what Eike said too.
-----Original Message-----
From: Simon Phipps [mailto:simon@webmink.com]
Sent: Monday, August 01, 2011 11:59
To: ooo-dev@incubator.apache.org
Subject: Re: Population of ooo-security
One observation about this discussion: Until there is actually a way to
make a binary deliverable from AOOo, any inbound security alerts would
probably need to be referred to LibreOffice anyway. While the Apache-only
list that's being speculatively designed here might be applicable once the
project is creating deliverables, but until then a pragmatic approach of a
temporary and inclusive list seems hugely preferable.
S.
Re: Population of ooo-security
Posted by Rob Weir <ap...@robweir.com>.
On Mon, Aug 1, 2011 at 8:30 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I'm assuming that, out of the mutual concerns we all share for the community of ODF supporters, that it might be appropriate to suggest to a reporter that they take their report to a different security@ address that might be more appropriate for immediate attention and action.
>
Yes. For example, if the question actually boils down to a user
support question, on how to use digital signatures, I'd refer them to
the support forums.
> - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:apache@robweir.com]
> Sent: Monday, August 01, 2011 16:58
> To: ooo-dev@incubator.apache.org
> Subject: Re: Population of ooo-security
>
> On Mon, Aug 1, 2011 at 7:40 PM, Simon Phipps <si...@webmink.com> wrote:
> [ ... ]
>> I don't think I understand how your response, which refers to the
>> functioning of a future list once AOOo has an operational development
>> process, applies to my comment, which refers to the situation now when any
>> incoming security issue would probably be triaged by fixing & recommending
>> use of LibreOffice.
>>
>
> The existence and staffing of ooo-security is part of AOOo
> development. It is not something outside of a development process.
> Not every report we receive necessarily results in the production of
> an urgent patch. But if such a situation occurred, then we'd discuss
> on ooo-security and develop a recommendation. But regardless of the
> disposition of the report, I think it is important to respect the
> privacy of the reporter.
>
>> S.
>>
>
>
RE: Population of ooo-security
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I'm assuming that, out of the mutual concerns we all share for the community of ODF supporters, that it might be appropriate to suggest to a reporter that they take their report to a different security@ address that might be more appropriate for immediate attention and action.
- Dennis
-----Original Message-----
From: Rob Weir [mailto:apache@robweir.com]
Sent: Monday, August 01, 2011 16:58
To: ooo-dev@incubator.apache.org
Subject: Re: Population of ooo-security
On Mon, Aug 1, 2011 at 7:40 PM, Simon Phipps <si...@webmink.com> wrote:
[ ... ]
> I don't think I understand how your response, which refers to the
> functioning of a future list once AOOo has an operational development
> process, applies to my comment, which refers to the situation now when any
> incoming security issue would probably be triaged by fixing & recommending
> use of LibreOffice.
>
The existence and staffing of ooo-security is part of AOOo
development. It is not something outside of a development process.
Not every report we receive necessarily results in the production of
an urgent patch. But if such a situation occurred, then we'd discuss
on ooo-security and develop a recommendation. But regardless of the
disposition of the report, I think it is important to respect the
privacy of the reporter.
> S.
>
Re: Population of ooo-security
Posted by Rob Weir <ap...@robweir.com>.
On Mon, Aug 1, 2011 at 7:40 PM, Simon Phipps <si...@webmink.com> wrote:
> On Mon, Aug 1, 2011 at 12:15 PM, Rob Weir <ap...@robweir.com> wrote:
>
>> On Mon, Aug 1, 2011 at 2:59 PM, Simon Phipps <si...@webmink.com> wrote:
>> > One observation about this discussion: Until there is actually a way to
>> > make a binary deliverable from AOOo, any inbound security alerts would
>> > probably need to be referred to LibreOffice anyway. While the Apache-only
>> > list that's being speculatively designed here might be applicable once
>> the
>> > project is creating deliverables, but until then a pragmatic approach of
>> a
>> > temporary and inclusive list seems hugely preferable.
>> >
>>
>> It is possible that some reports would be shared. It is also possible
>> that some would not. For example, a report might be a duplicate. It
>> might be wrong. It might be spam. It might require a followup to
>> clarify. It might involve code that doesn't exist in LibreOffice. The
>> discretion with the PPMC and their delegates.
>>
>> The Apache Security page makes it clear to reporters that they are
>> reporting a vulnerability to Apache where it will be discussed
>> privately by the project team. They are not told that their report,
>> with their name, company affiliation and other contact info, will be
>> shared more broadly than that. So even in instances where we did
>> share information, such as with a 3rd party expert or via a
>> pre-notification, that initial report would only be shared in
>> anonymized form.
>>
>
> I don't think I understand how your response, which refers to the
> functioning of a future list once AOOo has an operational development
> process, applies to my comment, which refers to the situation now when any
> incoming security issue would probably be triaged by fixing & recommending
> use of LibreOffice.
>
The existence and staffing of ooo-security is part of AOOo
development. It is not something outside of a development process.
Not every report we receive necessarily results in the production of
an urgent patch. But if such a situation occurred, then we'd discuss
on ooo-security and develop a recommendation. But regardless of the
disposition of the report, I think it is important to respect the
privacy of the reporter.
> S.
>
Re: Population of ooo-security
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
FWIW;
--- On Mon, 8/1/11, Simon Phipps <si...@webmink.com> wrote:
>
> I don't think I understand how your response, which refers
> to the functioning of a future list once AOOo has an
> operational development process, applies to my comment,
> which refers to the situation now when any incoming security
> issue would probably be triaged by fixing & recommending
> use of LibreOffice.
>
I think we can handle it by ourselves already. If there is an
urgent security issue we want to know right away and we can
apply fixes to the apache-extras repository.
If there is need we could even do a 3.4 source release
there too.
cheers,
Pedro.
Re: Population of ooo-security
Posted by Simon Phipps <si...@webmink.com>.
On Mon, Aug 1, 2011 at 12:15 PM, Rob Weir <ap...@robweir.com> wrote:
> On Mon, Aug 1, 2011 at 2:59 PM, Simon Phipps <si...@webmink.com> wrote:
> > One observation about this discussion: Until there is actually a way to
> > make a binary deliverable from AOOo, any inbound security alerts would
> > probably need to be referred to LibreOffice anyway. While the Apache-only
> > list that's being speculatively designed here might be applicable once
> the
> > project is creating deliverables, but until then a pragmatic approach of
> a
> > temporary and inclusive list seems hugely preferable.
> >
>
> It is possible that some reports would be shared. It is also possible
> that some would not. For example, a report might be a duplicate. It
> might be wrong. It might be spam. It might require a followup to
> clarify. It might involve code that doesn't exist in LibreOffice. The
> discretion with the PPMC and their delegates.
>
> The Apache Security page makes it clear to reporters that they are
> reporting a vulnerability to Apache where it will be discussed
> privately by the project team. They are not told that their report,
> with their name, company affiliation and other contact info, will be
> shared more broadly than that. So even in instances where we did
> share information, such as with a 3rd party expert or via a
> pre-notification, that initial report would only be shared in
> anonymized form.
>
I don't think I understand how your response, which refers to the
functioning of a future list once AOOo has an operational development
process, applies to my comment, which refers to the situation now when any
incoming security issue would probably be triaged by fixing & recommending
use of LibreOffice.
S.
Re: Population of ooo-security
Posted by Rob Weir <ap...@robweir.com>.
On Mon, Aug 1, 2011 at 2:59 PM, Simon Phipps <si...@webmink.com> wrote:
> One observation about this discussion: Until there is actually a way to
> make a binary deliverable from AOOo, any inbound security alerts would
> probably need to be referred to LibreOffice anyway. While the Apache-only
> list that's being speculatively designed here might be applicable once the
> project is creating deliverables, but until then a pragmatic approach of a
> temporary and inclusive list seems hugely preferable.
>
It is possible that some reports would be shared. It is also possible
that some would not. For example, a report might be a duplicate. It
might be wrong. It might be spam. It might require a followup to
clarify. It might involve code that doesn't exist in LibreOffice. The
discretion with the PPMC and their delegates.
The Apache Security page makes it clear to reporters that they are
reporting a vulnerability to Apache where it will be discussed
privately by the project team. They are not told that their report,
with their name, company affiliation and other contact info, will be
shared more broadly than that. So even in instances where we did
share information, such as with a 3rd party expert or via a
pre-notification, that initial report would only be shared in
anonymized form.
-Rob
> S.
>
Re: Population of ooo-security
Posted by Simon Phipps <si...@webmink.com>.
One observation about this discussion: Until there is actually a way to
make a binary deliverable from AOOo, any inbound security alerts would
probably need to be referred to LibreOffice anyway. While the Apache-only
list that's being speculatively designed here might be applicable once the
project is creating deliverables, but until then a pragmatic approach of a
temporary and inclusive list seems hugely preferable.
S.
Re: Population of ooo-security
Posted by Rob Weir <ap...@robweir.com>.
On Mon, Aug 1, 2011 at 2:04 PM, Eike Rathke <oo...@erack.de> wrote:
> Hi Rob,
>
> On Saturday, 2011-07-30 17:41:28 -0400, Rob Weir wrote:
>
>> > Regarding Apache OpenOffice.org, LibreOffice, Symphony, RedOffice,
>> > NeoOffice, BrOffice, EuroOffice, etc. as siblings that share similar
>> > code in their genes from the ancestor OpenOffice.org, this approach has
>> > a shortcoming in collaboration.
>>
>> The purpose of ooo-security is security. Any other concerns,
>> including collaboration with other projects, or even including
>> collaboration within this project, are secondary.
>
> I was referring collaboration on security, for the benefit of all.
>
Committers chosen by the PPMC collaborate on resolution of security
issues today on the ooo-security list. If someone wants to take part
in this collaboration, then they are welcome to do it. It starts with
becoming a committer on the project.
>> > Given that usually users / developers / security experts report
>> > a problem to _their_ project's security team, this setup would mean
>> > a one-way communication if that project decided to inform AOOo, actually
>> > being a pre-notification in that direction. What is that project
>> > expected to do from that point on? Wait until AOOo publishes the
>> > disclosure and fix? I think the project would develop its own fix and,
>> > hopefully, share it with AOOo (which would involve a CLA or a permissive
>> > license or a grant) and also with other siblings.
>> >
>>
>> We've already discussed and generally agreed that we can pre-notify
>> other related projects about vulnerabilities and fixes. But
>> pre-notification is not the same as saying that the other projects
>> must be signed up to on ooo-security.
>
> Well, my example was about pre-notification in the other direction, from
> siblings to AOOo.
>
Sorry, I misunderstood. I assume any other project would follow their
own rules. Ideally, there would be a pre-notification state that
stands between that team's initial investigation and proposed
resolution and public notification. That is what some other Apache
projects are doing, and that is what I'm proposing for us.
>> > Now if siblings develop fixes independently because AOOo security runs
>> > as a strict Apache closed coterie, we may get into the situation where
>> > fixes are developed in parallel, maybe with different solutions or even
>> > contradictory. I think the best would be if efforts would be bundled
>> > instead and the best of all possible solutions shared as
>> > pre-notification with siblings.
>> >
>>
>> There is nothing wrong with pre-notification. That was my step #3 above.
>>
>> Your example seems to be assuming that a single reporter reports the
>> same flaw to OpenOffice, LibreOffice, Symphony, etc., independently,
>
> No, my example was assuming that a single reporter reports only to one
> project, which I think is the usual case. Further assumption was that
> project would decide to pre-notify AOOo, knowing the same code is
> affected.
>
OK. That's all true. To the extent that we're not working off a
single code base, the possibility that "fixes are developed in
parallel, maybe with different solutions or even contradictory" exists
everywhere. This is not something special with security. It will
occur with every are of the products.
But with pre-notification, this doesn't need to be a problem. If we
pre-notify with a patch under Apache 2.0, then anyone can use that
patch. If others do the same, then we could as well.
>> and that these projects develop patches independently. I suspect that
>> this occurrence is quite rare. But I don't see that harm if it does
>> happen. The fact is these projects are not sharing code today,
>> period.
>
> Au contraire, you're right the projects aren't sharing code, in that
> case a fix and update would be sufficient, but most projects still use
> the same if not identical code in areas where security issues may be
> discovered.
>
I don't think we're in disagreement here, and if we shared code we'd
have less overlapping work. I'm just pointing out that security
vulnerability patches amount to something like 0.1% of all code
changes that we could be sharing. So if you are looking for
meaningful ways to collaborate with LibreOffice then this is the wrong
place to look. I'd focus on parts where we can work together openly,
like in file import/export filers, plugins, etc.
>> This is not just a statement about security. If we want to
>> improve that situation with security specifically then we have two
>> easy ways forward:
>>
>> 1) Develop the patches at Apache under a license that allows all other
>> products to use it
>>
>> 2) Have security experts from LibreOffice developers join as Apache
>> committers so they can then join the ooo-security list and contribute
>> directly there.
>
> An ideal situation I support. And btw, I wasn't talking of only
> LibreOffice..
>
Good.
>
>> > The problem here seems to be the perceived requirement that the Apache
>> > governance would allow only PMC members on a project's security list.
>> > However, I didn't see that requirement, or it's not available somewhere
>> > under http://apache.org/security/
>> >
>> > Additionally http://apache.org/security/committers.html states that
>> >
>> > | Information may be shared with domain experts (eg colleagues at your
>> > | employer) at the discretion of the project's security team providing
>> > | that it is made clear that the information is not for public disclosure
>> > | and that security@apache.org or the project's security mailing list must
>> > | be copied on any communication regarding the vulnerability.
>> >
>> > This IMHO allows also to have selected members of sibling projects as
>> > domain experts on the security list, if I interpret "at the discretion
>> > of the project's security team" correctly.
>> >
>>
>> There is nothing there that talks about having these domain experts be
>> list members. In fact, it specifically talks about "copying"
>> security@apache.org. That would not be necessary if the domain
>> experts were security list members, since all list project security
>> traffic is copied automatically to security.apache.org as well. Thus
>> the information sharing implied here is through means other than
>> subscription to the list.
>
> To me it only sounds like that for any communication regarding the
> vulnerability the project's (or apache) security list must be copied, so
> information is shared when the domain expert communicates with a list
> member and even if he consults another colleague. Of course the language
> implies that the domain expert is not a list member, but "at the
> discretion of the security team" is a degree of freedom to decide whom
> to copy when, and if the team decides to get another expert on board on
> a regular basis that's just fine.
>
> Also, if all traffic were automatically
>> copied to 3rd party domain experts via their subscription to the list,
>> then there would be zero discretion being exercised.
>
> Given that only a hand full of known, respected and trusted persons
> would be invited I don't see much difference whether they are Apache
> committers or not, provided that the patches developed will be
> contributed under AL2.
>
Remember, on any Apache list, we can bring in non-subscribers for a
discussion. We just send an email to the list and cc the 3rd party.
If the 3rd party then does a "reply to all", their email will go
through to the list. Since the list is intended for 3rd party
(public) submission of reports, anyone can post to it. So we can have
a conversation on a specific issue on the ooo-security list, and
include 3rd parties.
I have no problems with this.
What I oppose is having 3rd parties subscribe to the list so they
automatically and by default get every single one of the raw,
unverified, unconfirmed, un-anonymized private reports that are
submitted to the project from the public.
If there are 3rd parties who are respected and trusted and committed
to this project, and knowledgeable about OOo security, then I invite
them to state so on this list and I'll gladly propose them as
committers.
-Rob
> Eike
>
> --
> PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
>