launchpad-dev team mailing list archive

[curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On 11/29/2011 05:41 PM, Francis J. Lacoste wrote:
> Public bug
> Disclosed security bug (public)
> Undisclosed security bug (governed by the security access policy)
> Private (governed by the privacy security access policy)
> User-data (governed by the apport security access policy)

I really like this proposal.

> We might even coopt the last policy for the cases of bugs becoming
> private because of personal information.

We could do this because we think this is valuable to large projects
with the skill of managing user-data would use this. I am not certain we
want to offer this because it makes it easy for projects to circumvents
our desire to restrict privacy to paying users.

> There is another case that we might want to consider. Private security
> bugs. Those would be bugs that are tagged security, but never intended
> for disclosure, and would remain private forever (security bug in a
> proprietary project like OEM for example, at least the part that
> contains conversation with the client). Like other bugs governed by the
> privacy policy. Not sure if this is useful or not. If we think of
> security has a tag, it probably makes sense.

I think this case of two bugs. A private bug because it contains client
information and the project talks to the client. The second security bug
involves the project (as a proxy) working with security team that might
be from another project.

> Another alternative is to keep the security aspect as a flag, (security
> related or not) and rename private to access_policy with an enum.
> 
> Enum values could be:
> 
> Public
> Embargoed (so restricted access for a limited time, mainly used for
> security issues, but maybe useful in other context)
> Private (never intended to be disclosed)
> User-data (should be confidential because it contains user data.)
> 
> It might be possible to see Embargoed and User-data as two facet of the
> same thing:
>  * Embargoed + security => security access policy
>  * Embargoed w/o security => "apport" security policy
> 
> Might be that this implicit modelling would be confusing (to the user
> and developer).
> 
> So we have really three attributes here:
> 
> * security - boolean flag
> * disclosure_policy - an enum like the above
> * access_policy - Actual access governing the bug based on the two above

I cannot make sense of this. It is hard to reconcile what we show users
(and what I see in the UI) with the actual implementation. I think this
requires extra code to manage. There is a lot of opportunity for
mismatches access like we have today -- people cannot see their bugs
because someone fiddled with the visibility and subscribers. I think
disclosure and access should be synonymous.

AccessPolicyType defines two policies at the moment: private and
security. We now we are going to add one for apport and I like your term
user-data. The UI can show Public for no policy. Security can remain a
flag, but we need to ensure the write policy is selected when the user
chooses a visibility enum or a private checkbox.

-- 
Curtis Hovey
http://launchpad.net/~sinzui

Attachment: signature.asc
Description: OpenPGP digital signature