Frank,
I repect you, but I strongly disagree with you here and with the
proposal. I believe that it is completely inadequate for an open-source
project.
Frank Hecker wrote:
> > What, if that bug or strongly related topics are discussed on the
> > mailing list? IMO, there should be a policy that those people are added
> > to the (email) cc list of such discussions.
>
> That's a reasonable request; however note that there's no technical way
> to ensure that a bug reporter gets cc-ed on all correspondence.
(I know. But policies don't necessarily have to be enforced by technology. )
> > Involvement of the original reporter is essential, because
> sometimes, he
> > is the only one involved who is really interested in getting the bug
> > fixed right. (This is nothing against anybody working on Mozilla, but a
> > general (sad) statement).)
>
> I agree 100%. That is why this policy tries to put the bug reporter at
> the center of the process of investigating and resolving security bugs,
But, apart from the bug reporter, users have a vivid interst in the bug
being fixed, just that they are not directly involved. Thus, mozilla.org
should represent also its users, maybe even primarily so, because
developers are already represented. That's why I think that mozilla.org
should do its share to force developers to fix these bugs.
The current proposal does nothing like that. In that proposal,
mozilla.org does not help users in any way, instead it favors only the
needs of some commercial distributors. It lays all burden on the
reporter, which might be identical to the commercial distributor or
which might be an unexperienced individual that is easily influenced.
> One major goal of this policy is to give potential reporters of security
> bugs a reason to work within the Mozilla project processes, as opposed
> to putting potential reporters in a position where they have to work
> outside those processes.
I can see the rationale, but you are going way too far to please
commercial bug reporters and do nothing for users. It is not balanced in
any way.
> > I strongly believe that each new bug reported confidentally should
> > *immediately* be reported in a vage way to the public.
[...]
> > I believe that the public has at least the right to know that there
> is a
> > bug and roughly where it is. This allows people to protect themselves,
[...]
> "What I object to is making it a precondition of forming the security
> [bug] group that mozilla.org mandate such warnings as a universal
> policy. While this may be the right thing to do in theory, in practice I
> think mandating such a policy would potentially lead to some Mozilla
> distributors choosing not to participate in the security group, and
> doing things on their own behind closed doors.
I do believe that mozilla.org, being an open-source project, has the
*obligation* to do the "right thing" and protect end-users*, testers and
developers. (*See below, why I include end-users.)
I see no valid reason for not wanting to have this kind of information
(vage warnings about bugs and workarounds) being publicized.
If there really are parties who would not disclose bug information under
these terms, they should speak up and defend their position here. We can
then decide, if the arguments are valid and if the information coming
from the disagreeing party is valueable enough for mozilla.org to do the
wrong thing and to risk the direct security and privacy of its
contributors and testers (the *other* "hands that feed it") for the sake
of getting this additional, confidental information. But I think that
even in that case, we could find a compromise.
If there is nobody objecting in that way, then we should make this a
policy, or at least allow someone in the security group to release such
warnings.
> And that in turn
> potentially lessens the benefit to everyone (including users) of having
> a security [bug] group in the first place.
I don't think so. I do think that the security bug group, as proposed,
is almost useless, apart from letting a few people (who *really* need to
see that info *anyway* and who should have seen it from the beginning)
see the bugs.
Actually, if you don't even allow me to warn my (Beonex end-)users about
new bugs and to give them workarounds, even seeing the bugs is hardly
useful for me as a distributor. I can also get the information, that a
bug has been fixed, from the CVS logs (although that is admittedly much
harder and obscure).
> I presume it means something like "#@?&!" :-)
(Correct. It was by accident, I sent this mail too early, sorry.)
> > If security-concious people get to
> > know about that, it drives them up the wall and they generally loose
> all
> > trust in that vendor. I don't think, mozilla.org should support such
> > irresponsible treatment of security bugs.
>
> As I said above, mozilla.org is prepared to step in if we feel that a
> particular vendor is abusing the system and trying to keep a bug
> confidential for an unreasonably long period of time.
If this condition is met whenever all distributors released a new
version after the bug was known, a condition that is relatively clearly
defined and can be processed almost automatically, why not make it a policy?
> > (OK, there is a problem to determine when all distributors released a
> > new product after a bug has been found. Maybe we can settle at
> > mozilla.org stable releases or something like that.)
>
> See where the complications begin to arise? :-)
I don't think, that's where they "begin", but end. It's the only problem
I see, and I think it can be solved similar to what I proposed above.
> > I go even further than say that mozilla.org should put some directed
> > pressure on its developers by making security bugs public after some
> > pre-defined amount of time. The pressure of publicity is the only
> > reliable way I know to get people fix security bugs in time and
> > correctly. Apart from pressure, publicity also gives more people a
> > chance to fix a bug.
>
> I agree.
Well, your proposal does not reflect this opinion at all.
> Again, that's why you as a bug reporter should and will have
> the power to force disclosure of Bugzilla data relating to your bug.
>
> The problems you're concerned about are mainly problems when the bug
> reporter is a Mozilla vendor with an incentive to keep the bug
> confidential.
Not only that. I am also concerned about occasional "outside" reporters.
Note that individual reporters usually have no opinion or experience on
the subject of disclosure, unless they are experts. That's why the
reporters will usually do what the engineers want, which is to wait with
disclosure.
("We had a problem here ... and there... We will be done on Monday...
We'll need another 2 days. Is that OK?.... The worst part is fixed, but
to fix it fully, we need one more week. Can you wait so long?... It is
fixed, but we need to make a new release, can you wait until the release
is out, so that users are not harmed? ...")
Maybe we could address that with some strict default rules, which can be
overridden by the reporter in the inital report (and only there).
If the reporter says nothing about disclosure, use mozilla.org's default
disclosure rules, which could be something like:
1. Immediately warn users, with a workaround
2. Disclose bug when fixed or 2 weeks after report, whatever comes first
3. Immediately notify users when the bug has been fixed.
However, the reporter also has the chance to explicitly deny the
disclosure (term 2 above) in the bug report, in which case it the policy
as you proposed it will take place. The security group, by vote, has the
ability to prevent the disclosure (term 2 above) for a limited time on a
case-by-case basis.
This still ensures that reporters have, if they really want to, the
ability to control disclosure (in most cases, unless they are overruled
on a case-by-case basis). But a strict disclosure policy will be in
place, if the reporter has no definite opinion on the subject. The
security group-overruling prevents the policy being applied when it's
grossly inappropriate.
(I don't think that this is a good policy, but it is a tiny bit better
than the current proposal IMO.)
> They can take advantage of their position as a bug
> reporter to try to keep the bug private.
That's the reason why I propose the above policy.
> Second,
> if the same bug gets reported by someone else then it can be worked on
> and disclosed independent of the recalcitrant vendor. (That's a major
> reason why the policy specifies that bug duplicates are treated as
> separate bugs are far as disclosure is concerned.)
Are you proposing that somebody from the security bug group, who read
the confidental bug filed by a Mozilla vendor, reports a new bug and
discloses that? That I would consider unfair against the vendor and
would render any confidence policy useless.
If it's someone else who's reporting, then it's irrelevant, because it's
a coincidence.
> We're not talking about continuing the current "Netscape Confidential"
> scheme. Under the proposed scheme Netscape would not have any formal
> power to keep bugs confidential
No, under the proposed scheme, it doesn't have to, because *nobody*
(apart from mozilla.org staff and the security owner/group?, in special
cases) has the power to disclose bugs. Apart from the reporter, of
course, who has this ability under both schemes.
> > Indeed. This "policy" is none. You simply never disclose security info.
> > I don't think that is right.
>
> Ben, where does this policy say we "never disclose security info"? If
> you report a bug then you decide when to disclose the information.
I said "you", meaning the mozilla.org project.
("Never" not being an absolute term, you say that mozilla.org staff
might decide in *some* cases to disclose bugs, but there is no *regular*
case for that. If you have a regular case in mind, please define it in
the policy.)
> If mozilla.org and/or the security module owner feels
> that a particular bug is being kept confidential for too long then they
> reserve the right to force disclosure on a case-by-case basis.
When will that be the case? How can I, as a Mozilla tester, trust you
(mozilla.org) that you will prevent me from exposing my private data to
the world while testing Mozilla?
> >> However we will ask all individuals and organizations reporting
> >> security bugs through Bugzilla to follow the voluntary guidelines
> below:
> >> * Please try not to keep bugs in the security-sensitive category
> >> for an unreasonably long amount of time.
> > You have to define that.
>
> But we can't define "unreasonably long" in a way that would correctly
> apply to each and every case.
But you have to give a *guideline*.
I, personally, would consider "reasonable" to give developers 1 or 2
weeks to fix the bug and release the bug to the public no later than
that, no matter, if it's fixed or not. What I saw and read about
security bugs seems to suggest that severe bugs are either fixed within
that time or will hardly ever get fixed right, if kept confidental.
Or do you mean "2 weeks after the next mozilla.org milestone"? Or "3
months after AOL and Netscape made its next release"?
How does a naive reporter know what's right, if even we can hardly agree?
> >> If disputes arise about whether or when to disclose information about
> >> a security bug, we ask that the parties involved discuss the issues
> >> via private email and try to reach consensus.
> >>
> > I think that should happen visibly to all members of the seucrity
> group,
> > not just the 2 parites in conflict.
>
> Encouraging this discussion to occur within the security bug group is
> fine by me.
Not just "encouraging", but making it policy. You cannot technically
prevent a developer to mail the reporter, but you can throw him out of
the security group, if you find it out.
> > Otherwise, Netscape or somebody else
> > might talk a reporter into keeping the bug closed longer than
> reasonable.
>
> I see nothing wrong with a vendor privately communicating with a bug
> reporter to make the case for keeping a bug confidential for a little
> while longer.
I do. Naive reporters will listen to someone working at Netscape (and
maybe being the mozilla.org-designated developer working on that bug).
Netscape will have an easy time talking reporters to keep bugs
confidental as long as Netscape pleases. Even if I am a security group
member, I won't know, if Netscape persuades reporters that way and I
can't advise the reporter to do otherwise.
> After all, the vendor might need to convey
> vendor-confidential information, like the fact that they have a release
> planned for a particular date.
*shrug* Their problem. The people on the security group are assumed to
be trusted. They have far more sensitive information already.
> And other members of the security bug
> group have the same opportunity to make their own views privately known
> to the bug reporter.
Am I supposed to mail each reporter, just in case Netscape mails him
privately?
[Technical schemes for pushing bugfixes to end-users.]
> I think that [...] should be considered by other vendors. However
> mozilla.org doen't have the power to force all vendors to implement a
> similar scheme.
They don't have to. But mozilla.org doesn't have to adjust its security
policy to unnecessarily unsecure release schemes of some vendors.
If vendor releases only once a year, are you going to wait for it? What
about half a year?
> > It isn't meant as offening as it might sound, but while you
> *considered*
> > all views, the view of Netscape is about the only one followed in this
> > policy.
>
> This policy reflects my views as well, and my views are not identical to
> Netscape's. In fact, I'm not even sure I know exactly what "Netscape's"
> views are in this context. This draft policy wasn't dictated by Netscape
> management, if that's what you mean, and it's quite possible that they
> might find things to object in it, just as you have.
The policy reflects what Netscape wants, as I understood it by Mitch's
posts. It does not reflect *at all* what I and many others who posted
here (partly years ago, when this came up first) think. The policy,
as-is, is completely unacceptable to me. Not "only" in a theoretical
sense, thinking of the good of users and the spirit of open-source, but
also speaking as a representative of Beonex.
> More correctly, "everything is controlled" by the security bug group
> (not necessarily a small group, depending on what you mean by "small"),
> by the bug reporter (who could be anyone), and ultimately by mozilla.org
> as overseer of the process.
The problem is that the public has no ability to control or review the
decisions. If neither the security group (as a whole) nor mozilla.org
staff nor the reporter decides that a bug will be disclosed, the public
won't even know that the bug exists or that there was an argument about
disclosing it. Even if there is a member of the security group
disagreeing with the decision, it cannot complain to the public (without
giving up its status as a security group member), because that would
mean to disclose at least vage information about a bug, which is also
disallowed.
That's why I think that a hard-and-fast rule to disclose bugs, before
nobody cares about them anymore, must be included, because otherwise
nobody can ever even make an informed decision about trusting the group
or not. You're creating a CIA for Mozilla ;-P.
> Regarding time limits for disclosure, as I
> wrote earlier I don't think it's possible or desirable to specify a
> single fixed time limit for disclosure; I would prefer to leave the
> time limit open, to be decided on a case by case basis, with enough
> checks and balances in the process to prevent people from abusing the
> system and sitting on bugs forever.
Nice that you say "checks and balances". DMCA et al proves that this
does not work in the US gov either.
