river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Hurley <Jim.Hur...@Sun.COM>
Subject Re: Handling security -related issues
Date Fri, 07 Sep 2007 13:56:55 GMT
On Sep 7, 2007, at 5:40 AM, Mark Brouwer wrote:
> Jim Hurley wrote:
>> :
>> :
>> Mark:  I was keying off your ideas on this from the email
>> thread, as well as your dialog with Jools and others.
>> I see the conflict if the field is named a certain way (e.g.,
>> "Security Issue",  but maybe that could be accommodated
>> by changing the field name to "Security Issue Under Committer  
>> Discussion"
>> or some such -- indicating that the issue is sensitive at this
>> stage (when marked) and needs to be private among the
>> Committers.  Thus, when unchecked, it's still a security issue,
>> just not under Committer private discussion.
>> Happy to go with an alternative suggestion here if anyone
>> has one.

Thanks for taking the lead on this, Mark.

> Ok, I did some reading and playing around with a JIRA instance. And
> although the label is "Security Level" (built-in field) we can have
> various levels with different groups of people assigned to them, e.g.:
> Security Level: "none" (this is the default built-in type)
> Security Level: "security risk, visible to committers only"
> Security Level: "security risk, visible to anyone"
> The second level makes that only committers of the River project have
> access to it (see the issue in their reports). The third level will be
> set to the group 'anyone' which makes it equivalent to 'none' in terms
> of visibility although it remains marked as a security issue.

Looks good.

> Still I think we must decide about whether we should make a security
> issue public even when solved when the way to exploit the security  
> issue
> is part of the issue description. Another option we have is that when
> the issue has been discussed we create a new issue that will have  
> as its
> description the rather vague descriptions you often see associated  
> with
> security patches. In that case we still need the 3 states of which I
> gave an example above.

Good point -- how is this handled in other Apache projects?

> BTW I believe it is important we keep the reporter in the loop so  
> he/she
> will have full access to the issue.

Definitely.  I'll make a note of this in the Proposal.

> Pending any final decision, given the fact we need this field anyhow
> (regardless the workflow we decide) I created for Apache River JIRA a
> security scheme so you can see it yourself. If you enter an issue you
> will be confronted with the additional 'Security Level' field which
> defaults to "none".
> -- 

Thanks again, Mark.  I'll rev the Proposal and get it out soon.


View raw message