river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: Handling security -related issues
Date Fri, 07 Sep 2007 09:40:06 GMT
Jim Hurley wrote:
> "How do I handle security -related issues on River?"
> Sounds like process to me...
> 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.

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.

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.

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

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".

View raw message