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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
