When the security flag changes, also change the subscription of the security contact

I think this probably makes sense.

There was discussion previously that sometimes some bugs would be so secret that only the security contacts for some of the affected software should be allowed to see it, but there's no evidence so far that Malone needs to handle that use case.

How would this work? Currently, if the bug is private, then the subscribers are always explicit. Are you suggesting to change that rule to be: if the bug is private but it is security-related then implicitly subscribe (and give access to) the related security contact?

A way to solve your problem more explicitly would be to change the way you change a security bug to be non-security-related, offering the option in that step to unsubscribe the security contact. That would be less controversial.

On Fri, Jan 05, 2007 at 12:48:50PM -0000, Christian Reis wrote:
> How would this work? Currently, if the bug is private, then the
> subscribers are always explicit. Are you suggesting to change that rule
> to be: if the bug is private but it is security-related then implicitly
> subscribe (and give access to) the related security contact?

Given that security is the primary use case for private bugs, this exception
seems worthy of consideration.

I've subscribed the security team to get their input. Maybe this isn't as
much of an issue as it once was, or there's a better way to address it.

--
 - mdz

I would agree that the multi-step process of unchecking "security" and then having to unsubscribe the security team is a hassle.

Brad's comments weren't clear to me, so I guess to have an opinion about this, I'd need to get the following clarified:

- who can flag/unflag a bug as being a security issue? (I would be uncomfortable if it were "just anyone" and things were changed so that the security team would become unsubscribed when the flag was unchecked. e.g. perhaps their definition and my definition of a "security issue" are different, and suddenly I'd silently stop getting any updates on the bug)

- who can read a bug report when it is flagged as private? (I have always assumed it is the subscribers. As the CVE tracking is moved into Malone there WILL be use-cases where we need a bug report to be visible ONLY to the security team and people explicitly subscribed to the bug. i.e. just because you have your bugmail settings setup to subscribe you to a package doesn't mean you should be able to see embargoed security bugs)

On Mon, Jan 08, 2007 at 06:08:02PM -0000, Kees Cook wrote:
> I would agree that the multi-step process of unchecking "security" and
> then having to unsubscribe the security team is a hassle.
>
> Brad's comments weren't clear to me, so I guess to have an opinion about
> this, I'd need to get the following clarified:
>
> - who can flag/unflag a bug as being a security issue? (I would be
> uncomfortable if it were "just anyone" and things were changed so that
> the security team would become unsubscribed when the flag was unchecked.
> e.g. perhaps their definition and my definition of a "security issue"
> are different, and suddenly I'd silently stop getting any updates on the
> bug)

I think anyone can do this, but an email notification is sent, so this
should never be silent.

> - who can read a bug report when it is flagged as private? (I have
> always assumed it is the subscribers. As the CVE tracking is moved into
> Malone there WILL be use-cases where we need a bug report to be visible
> ONLY to the security team and people explicitly subscribed to the bug.
> i.e. just because you have your bugmail settings setup to subscribe you
> to a package doesn't mean you should be able to see embargoed security
> bugs)

I believe only explicit subscribers (including the assignee?) and Launchpad
administrators have access to private bugs. Kiko can confirm.

--
 - mdz

HI,

Matt Zimmerman [2007-01-08 16:26 -0000]:
> On Fri, Jan 05, 2007 at 12:48:50PM -0000, Christian Reis wrote:
> > How would this work? Currently, if the bug is private, then the
> > subscribers are always explicit. Are you suggesting to change that rule
> > to be: if the bug is private but it is security-related then implicitly
> > subscribe (and give access to) the related security contact?
>
> Given that security is the primary use case for private bugs, this exception
> seems worthy of consideration.

Indeed I have the feeling that the number of unjustified
security/private bugs went down a bit, but there are still enough to
be a (minor) annoyance.

What about if the 'security' flag simply entails an implicit
subscription to the product's security contact, independently of
privacy? Then unsubscription would be an one-step procedure, and the
simple rule only involves one flag and is easy to understand. This
would make it impossible for the security team to stop getting mail
for a particular security bug they are not interested in, but this
seems like a corner case to me. I certainly don't mind being informed
about universe security issue progress even though I mostly do not
work on them. Kees, what about you?

Pitti

On Tue, Jan 09, 2007 at 08:45:07AM -0000, Martin Pitt wrote:
> What about if the 'security' flag simply entails an implicit
> subscription to the product's security contact, independently of
> privacy? Then unsubscription would be an one-step procedure, and the
> simple rule only involves one flag and is easy to understand. This
> would make it impossible for the security team to stop getting mail
> for a particular security bug they are not interested in, but this
> seems like a corner case to me. I certainly don't mind being informed
> about universe security issue progress even though I mostly do not
> work on them. Kees, what about you?

That's fine, and I think it's how the behavior currently works (I don't
think you can unsub security without having first unchecked the
"security" flag). And I absolutely want to get notifications for
universe security updates, so this is perfect for me too.

The only other thing I want is the ability to filter bug searches by
component so I can review main/restricted only, etc. I already filed
this as bug 74067.

--
Kees Cook

No, you can unsubscribe security -- it has no real relation to the security flag once the bug has been filed. It's an interesting angle having the security contact be an implicit subscription. But I should point out that there is no way to unsubscribe an implicit subscriber today, so you'd get mail on any and all security-related bugs.

Okay, this change has cause a serious regression in my ability to monitor security bugs. :( The "implicit" subscription doesn't appear to be doing anything except letting me view the bugs. I need two things:

- to be notified when a security bug changes/created
- to have bugs show up as being subscribed to

For example, I check for security bugs with:
https://launchpad.net/%7Eubuntu-security/+subscribedbugs

This list does not show:
https://launchpad.net/ubuntu/+bug/90662

Also, I never got an emails about 90662 being created/tagged.

Is there some other way to search for security bugs, at this point, it was just blind luck that this was discovered since Brian saw the above bug and brought it to my attention.

Which gets to the next issue:

When someone creates a new bug, since the "security" flag does not exist on the "open bug" page, it gets Ubuntu-Bugs subscribed, and when they mark it "private", it results in anyone on the bug squad being able to read the report. Also, I'm guessing initial emails are sent, so if sensitive information is contained in the description, it ends up in an email archive before they can flag it private/security.

What change are you referring to, Kees? This hasn't changed anytime recent, really.

The bug you are referring to never had the security team subscribed to it. I think what we want is that we subscribe the security team automatically to the bug when it is marked security sensitive (no matter where in the bug's lifecycle). That would solve the subscription problem and mitigate the latter issue you point out, about there not being a security flag to set when filing a bug.

The latter issue is indeed a problem because people don't file bugs as security right off the bat any longer. However, when I last spoke to Martin he said he wasn't sure that wasn't a feature, since the number of bugs that were misreported in the past was huge. We can revisit that, though, if you both think that's the right thing to do.

On Sat, Mar 17, 2007 at 12:14:50AM -0000, Christian Reis wrote:
> What change are you referring to, Kees? This hasn't changed anytime
> recent, really.

It seems that ubuntu-security is no longer "actually" subscribed when
the "security" flag is checked. As a result, I cannot (quickly) find
security-flagged bugs, and additionally get no email when
security-flagged bugs have changes made.

> The latter issue is indeed a problem because people don't file bugs as
> security right off the bat any longer. However, when I last spoke to
> Martin he said he wasn't sure that wasn't a feature, since the number of
> bugs that were misreported in the past was huge. We can revisit that,
> though, if you both think that's the right thing to do.

Right. I'm not sure what to do here. There were some bugs (though not
a *huge* number) being incorrectly flagged. I'd almost prefer the old
situation over the current one of having potentially private reports
leaking out into the mailing list.

Hi,

Kees Cook [2007-03-17 3:05 -0000]:
> Right. I'm not sure what to do here. There were some bugs (though not
> a *huge* number) being incorrectly flagged. I'd almost prefer the old
> situation over the current one of having potentially private reports
> leaking out into the mailing list.

Me too.

Private bugs only make sense at all if they are private right from the
beginning. Usually the initial email already contains all the details
and the followups are mostly just status updates, etc.

Subscribing ubuntu-security to security bugs is also vital for fast
processing. Polling Malone for new issues does not work for this IMHO.

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

Untargeting this for now to help with planning. Will retarget it later.

I'm re-prioritising this since it's an obvious problem for the Ubuntu security team.

This isn't a lot of work and is quite important to fix, so let's try to get this in this cycle.

Fixed in devel r8289.