launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On 09/18/2012 12:19 PM, Aaron Bentley wrote:
> On 12-09-18 11:03 AM, Curtis Hovey wrote:
>> There are groups of people interacting with a project and they use 
>> different information types.
> 
>> * Project Creators use Public, Proprietary, and Embargoed for
>> planning. * Project Community uses Public, Private (user), Private
>> Security
> 
> I don't understand this distinction.  It seems like "creator" actually
> means "owner" or "planner", since people who had no role in the
> creation of the project could wind up filing proprietary bugs later.

I use creator because Launchpad owner, maintainer, driver, and shared
organisation do not properly encompass the case where Canonical "owned"
projects are proprietary. Our organisation delegates the responsibility
to deliver or maintainer the project to many people. People in these
project roles are the core people who clearly are creators of features.
The people the project shares with are also placed in the role of
creators, though they rarely will make use of it.

> I think you're describing three categories
> Project Community, Project Creators who are not planning, who behave
> the same, and Project Creators who are planning, who use different
> types.  (I split Project Creators into planning and non-planning to
> reconcile with your later statement "The creators also work with
> [Public, Private (user), Private Security].")

This case has never been demonstrated to be true in Launchpad's data,
but we do recognise it can happen. We called YAGNI on the case. For
example, of the project that want to be proprietary, only 1 bug was
every filed as a Private Security bug in 6 years. It was a mistake.
Proprietary projects treat use other projects (via information bug
linking) to manage Private Security and Private (user) bugs.

> I don't think this is accurate, because some projects will use
> Proprietary and Embargoed regardless of whether they are planning.
> 
> Perhaps you meant:
>  * Project Creators use Public, Proprietary,
>    and Embargoed for planning, and all available types when not
>    planning.
>  * Project Community uses Public, Private (user), Private Security
> 
> Is that it?  It seems to disagree with this next statement, which
> implies that creators do not create Private (user) or Private Security.
> 
>> Project, teams, and blueprints originate from the creators, so they
>> can only be Public, Proprietary, and Embargoed
> 
> It's certainly *possible* for a blueprint to be security-related.
> Similarly, it can contain private user data.  I think the reason we
> exclude those information types from Specifications is because we
> don't think it's common enough to support.  I don't think it's because
> they originate from planning creators.  Also, we don't prevent
> non-creators from creating blueprints.

Not so, the blueprint can be edited to remove the personal information
about a user. While a blueprint may intend to solve a systemic security
issue, it does not contain the security issue, nore does it contain the
way to exploit the issue. Bugs do. While someone could put this
information in the blueprint, it can be trivially removed. The external
specification might contain details of the issue.

Consider that we did find cases where branches contained Private (user)
data. The fix is the delete the branch. A branch might exist to remove
personal data that is already committed. This happened 3 times in that
we know about. No user has ever asked for the feature. We decided that
Admins can set branches to Private, but users will see Proprietary and
Private Security.


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

Attachment: signature.asc
Description: OpenPGP digital signature