Security contacts are not notified when the project is not shared

[Curtis Hovey]

The Security Contact role exists to get notifications about embargoed and unembargoed security issues. Setting a team in that role does not share Embargoed Security information with them.

I think we image the Security Contact as having an implicit structural subscription, the role must get notification so it is not implemented as a structural subscription which can be deleted. The role is shown in the UI so that user reporting or reviewing bugs know who to discuss security issues with.

We might solve this as we do with assignments and subscriptions; when I set the Security Contact, Lp explains that the project does not share Embargoed Security information with them and offers to do that for the user. If we do this, we need to update both the bugs page and the configure bug tracker page to ajax.

[Curtis Hovey (sinzui)]

-- Under the old rules the default person to get security bug mail
-- is the maintainer. The maintainer may set the security contact to
-- another person.
-- Under the new rules, the maintainer gets full access by default,
-- but the security contact ceases to exist. But the maintainer
-- may still share all security info with a person who may set
-- a structural subscription.
-- We only want to share security with exclusive security_contact
-- persons for active projects that use Lp Bugs.
-- these team need a structural subscription for with a securty filter.
select p.name, sc.name
from product p
    join person sc on p.security_contact = sc.id
where
    p.active is true
    and p.official_malone is true
    and sc.subscriptionpolicy in (1, 3)
    and p.owner != p.security_contact
order by sc.name
;
-- (1006 rows) on staging
-- Note that there is a large overlap with the teams in this query
-- and those in the counterpart bug supervisor query. The overlaping
-- teams will ultimately have the same AGPs as the maintainer.

[Robert Collins (lifeless)]

I propose that we delete the 'security contact' role entirely. We can show the subscribers granted security visibility in some appropriate place, if we think its needed. I know we have some bits in the UI that say who will be notified of new bugs of different types. Perhaps that should just be made more generic and fixed (because we don't list /all/ the structural subscribers of public bugs, for instance. It wouldn't make sense.

[William Grant (wgrant)]

On 05/08/12 19:01, Robert Collins wrote:
> I propose that we delete the 'security contact' role entirely. We can
> show the subscribers granted security visibility in some appropriate
> place, if we think its needed. I know we have some bits in the UI that
> say who will be notified of new bugs of different types. Perhaps that
> should just be made more generic and fixed (because we don't list /all/
> the structural subscribers of public bugs, for instance. It wouldn't
> make sense.

The abolition of the security contact role has been concretely planned
for several months, and on my agenda for more than a year. This bug
mostly covers the migration aspect, and potentially initial configuration.

[Ian Booth (wallyworld)]

Security contacts which are exclusive teams now have for their projects:

- an access policy grant for private security artifacts
- a structural subscription filtered on information type = private security

So now the code which explicitly deals with security contacts, giving them access and notifications, can be removed.