2005-02-14 - Summary of mozilla.org staff meeting
Gervase Markham
-------------------------------------------------
Present: chase, gerv, dave, blizzard, jst, asa, chofmann, myk, dbaron,
ben, mscott, cbeard, rafael, dougt, dveditz.
*Mozilla 1.8b*
- Plan is to put security fixes on the trunk, release that, get
feedback, and release Firefox 1.0.1 after that
- Two more security fixes have got approval
- 23 blockers left; 11 have approvals but haven't landed
- 5 new nominations
*Firefox 1.0.1*
- Worried about the ByteVerifier trojan; want to have a warning on start
page
- Need to get 1.4.2_06 or 1.5 to be protected
- Should make some noise about this - "critical update from Sun"
*UMO*
- Not yet ready to go
- They have the setup in place they want to ship with, but not tested
yet
- Some testing was done over the weekend
- 18th and 25th dates optimise our ability to update clients (because of
"first week" bug and weekend effects)
- 18th is aggressive but it might just happen
*Firefox 1.1/Thunderbird 1.1*
- Not much to talk about; focus on 1.8b and 1.0.1
*Contributor Awards*
- On the back burner for this week
*IDN/punycode domain spoofing*
- Make sure the pref works so people can turn it off (done)
- Default the pref to off for 1.0.1 and 1.8b; provide XPI or
instructions to turn it on
- Make it clear it's a registrar/registry issue, but we are protecting
our users in the short term
- What to do long term is a drivers issue
- Need to have a discussion with Verisign, and find their plan for their
plugin
*PSM*
- kaie is part time, but he doesn't want full responsibility
- request for recruitment of PSM helpers (Seamonkey/Thunderbird security
UI)
- collaborative, iterative, open development (not closed for 6 months
and turn up with a 'finished' product)
- ben and mscott are watching the certificate value discussion in
n.p.m.security.
*Emphasising Security*
- MF will be hiring a security guy/more security resources
- rafael working with PR firm about messaging: security features
prominently
- dveditz was employed a year ago to focus on security
Gerv
Robert Accettura
> 2005-02-14 - Summary of mozilla.org staff meeting
> -------------------------------------------------
>
> Present: chase, gerv, dave, blizzard, jst, asa, chofmann, myk, dbaron,
> ben, mscott, cbeard, rafael, dougt, dveditz.
>
> *Mozilla 1.8b*
>
> - Plan is to put security fixes on the trunk, release that, get
> feedback, and release Firefox 1.0.1 after that
> - Two more security fixes have got approval
> - 23 blockers left; 11 have approvals but haven't landed
> - 5 new nominations
>
> *Firefox 1.0.1*
>
> - Worried about the ByteVerifier trojan; want to have a warning on start
> page
> - Need to get 1.4.2_06 or 1.5 to be protected
> - Should make some noise about this - "critical update from Sun"
With the emphasis on security, perhaps it's necessary for Firefox once a
week (or 2) to contact UMO and check latest plugin versions. So that we
can prompt "Plugin XXX has been updated".
This is more intiuitive to the user, and gets everyone. I'm curious how
many still use the Firefox start page. I'd bet not that many.
HJ
> 2005-02-14 - Summary of mozilla.org staff meeting
> -------------------------------------------------
>
> - MF will be hiring a security guy/more security resources
> - rafael working with PR firm about messaging: security features
> prominently
> - dveditz was employed a year ago to focus on security
The Mozilla Foundation makes it virtually impossible for people to fix
security related bugs, because this kind of bugs are 'undisclosed' for
them, and there are still a lot of them untouched/unsolved!
Say, what if someone likes to help/fix some bugs, but he doesn't know
where to start? Do you have a protocol for this?
Also, how can extension writers, people like me, get a handle on
security issues, before they are fixed and made public?
Please note that I am working on add-ons/extensions, like MultiZilla,
for over five (5) years already, but I still have to fight this the hard
way.
Btw, there's this bounty program for (serious) security bugs, but who
determines if a bug is 'serious' or not? Also, I never read anything, or
I completely missed it, that someone got his/her $500 bounty, why is that?
/HJ
Gervase Markham
> The Mozilla Foundation makes it virtually impossible for people to fix
> security related bugs, because this kind of bugs are 'undisclosed' for
> them, and there are still a lot of them untouched/unsolved!
How do you know there are still a lot unsolved if they are undisclosed?
> Say, what if someone likes to help/fix some bugs, but he doesn't know
> where to start? Do you have a protocol for this?
The best thing to do is contact Dan Veditz, and ask if there's anything
you can do to help.
> Also, how can extension writers, people like me, get a handle on
> security issues, before they are fixed and made public?
What sort of security issues do you need to know about?
Gerv
HJ
> HJ wrote:
>
>>Also, I never read anything, or
>>I completely missed it, that someone got his/her $500 bounty, why is that?
>
>
> Mozilla community sites, and on mozilla.org:
> http://www.mozilla.org/press/mozilla-2004-09-14-01.html
"Don't know why you missed it."
Oh but I do. I only returned from 'deep down under' on September 25th,
after being away for four long months, so no wonder I missed it...
Thanks for the info Peter ;)
James Graham
> HJ wrote:
>
>> Also, how can extension writers, people like me, get a handle on
>> security issues, before they are fixed and made public?
>
>
> What sort of security issues do you need to know about?
>
Well, for example, any changes in chrome javascript for security
reasons, (many extensions, particularly large ones will replace bits of
chrome code with their own version), changes to best practice (if there
was any clearly documented best practice to begin with) when using
certian objects, that sort of thing. At the moment, the only way for
extension authors to deal with this is to keep a permanent bonsai-watch
and follow-up on any suspicious looking checkins. Understandably, few
bother.
HJ
> HJ wrote:
>
>> The Mozilla Foundation makes it virtually impossible for people to fix
>> security related bugs, because this kind of bugs are 'undisclosed' for
>> them, and there are still a lot of them untouched/unsolved!
>
> How do you know there are still a lot unsolved if they are undisclosed?
Gerv, I've had the "You are not a member of the security group"
discussion before, with Jesse Ruderman, so I don't need no further
comments from anyone. Anyway, I just know, and it is true, that's a
fact, don't deny it!
>> Say, what if someone likes to help/fix some bugs, but he doesn't know
>> where to start? Do you have a protocol for this?
>
>
> The best thing to do is contact Dan Veditz, and ask if there's anything
> you can do to help.
I sort of asked him the same questions already, but he didn't reply, so
what's next?
>> Also, how can extension writers, people like me, get a handle on
>> security issues, before they are fixed and made public?
>
> What sort of security issues do you need to know about?
I'm only interested in browser related security issues, not mail and
what not.
/HJ
Gervase Markham
> Well, for example, any changes in chrome javascript for security
> reasons, (many extensions, particularly large ones will replace bits of
> chrome code with their own version), changes to best practice (if there
> was any clearly documented best practice to begin with) when using
> certian objects, that sort of thing. At the moment, the only way for
> extension authors to deal with this is to keep a permanent bonsai-watch
> and follow-up on any suspicious looking checkins. Understandably, few
> bother.
I can certainly see how you need to know about these as soon as a fix is
developed and checked in (and maybe there should be a mailing list for
that), but do extension authors need to know about these issues while
the bug is still closed?
Gerv
James Graham
Probably notification on checkin would be good enough.
Boris Zbarsky
>> The Mozilla Foundation makes it virtually impossible for people to fix
>> security related bugs, because this kind of bugs are 'undisclosed' for
>> them, and there are still a lot of them untouched/unsolved!
>
> How do you know there are still a lot unsolved if they are undisclosed?
Gerv, I'm frankly quite surprised you'd make a specious argument like this.
Bugs like this come up in comments in other (not security-sensitive) bugs, and
then it's easy to search bonsai to see whether a fix was ever checked in). The
fact that a bunch of these bugs are open is a badly-kept secret, if it's meant
to be a secret.
To be precise (and I believe I'm within the bounds of the mozilla.org security
policy of "don't say what the specific issues are" here), there are currently 64
open security-sensitive bugs in the "Core" product (this excludes bugs on
chatzilla, etc; also excludes firefox-specific bugs, of course) that are
"confirmed" (that is, not UNCONFIRMED). There are 12 more Core UNCONFIRMED bugs
with the security flag set.
Now of these bugs, a number should not be security-sensitive, imo (and in the
opinion of Dan Veditz, who explicitly said as much in the comments on the ones
that I looked at which looked particularly egregious). The number of actual
open security issues in Core is likely much significantly lower than the "64" we
have for confirmed security-sensitive bugs....
-Boris
Doug Wright
> To be precise (and I believe I'm within the bounds of the mozilla.org
> security policy of "don't say what the specific issues are" here), there
> are currently 64 open security-sensitive bugs in the "Core" product
> (this excludes bugs on chatzilla, etc; also excludes firefox-specific
> bugs, of course) that are "confirmed" (that is, not UNCONFIRMED). There
> are 12 more Core UNCONFIRMED bugs with the security flag set.
>
> Now of these bugs, a number should not be security-sensitive, imo (and
> in the opinion of Dan Veditz, who explicitly said as much in the
> comments on the ones that I looked at which looked particularly
> egregious). The number of actual open security issues in Core is likely
> much significantly lower than the "64" we have for confirmed
> security-sensitive bugs....
>
> -Boris
I hope these are all blockers for the 1.7.6/1.0.1 releases...
Boris Zbarsky
> Boris Zbarsky wrote:
>> Now of these bugs, a number should not be security-sensitive, imo
>
Why do I get the sense you stopped reading somewhere in the middle of the second
paragraph of my three-paragraph post?
-Boris
HJ
Gerv, please visit: http://www.mozilla.org/foundation/EULA/firefox-en.html
(note that I was unable to find one for Mozilla, but that's
probably because it is not targetted to End Users)
and scroll down to: 4. DISCLAIMER OF WARRANTY...
and note the "SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR
LIMITATION OF IMPLIED WARRANTIES, SO THIS DISCLAIMER MAY NOT APPLY TO YOU."
Scroll down to: 5. LIMITATION OF LIABILITY...
and note the "SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR
LIMITATION OF INCIDENTAL, CONSEQUENTIAL OR SPECIAL DAMAGES, SO THIS
EXCLUSION AND LIMITATION MAY NOT APPLY TO YOU."
Shit happens you know, just a matter of time, and I don't want to wait
ill prepared.
/HJ
asa dotzler
> Gervase Markham wrote:
>
>>> The Mozilla Foundation makes it virtually impossible for people to
>>> fix security related bugs, because this kind of bugs are
>>> 'undisclosed' for them, and there are still a lot of them
>>> untouched/unsolved!
>>
>>
>> How do you know there are still a lot unsolved if they are undisclosed?
>
>
> Gerv, I'm frankly quite surprised you'd make a specious argument like
> this.
I don't believe that we have a lot of unsolved security bugs that are
undisclosed.
I think I'd describe our unsolved security-related bugs as a fairly
manageable list and something reasonably less than "a lot".
We've ever had 1012 bugs in the secure group and we're doing our best to
stay on top of that, clearing out bogus ones, dupes, etc., and fixing
the real ones. The current list is probably a combination of bogus ones,
dupes, and bugs that need to be fixed and I think it's probably a
manageable list given the size of the security group and the rate at
which we've been plowing through them recently.
I don't think that what we currently have behind closed doors qualifies
as "a lot" of untouched or unsolved security issues. You seem to agree
in your next paragraphs, so what are you calling Gerv out on, exactly?
> To be precise (and I believe I'm within the bounds of the mozilla.org
> security policy of "don't say what the specific issues are" here), there
> are currently 64 open security-sensitive bugs in the "Core" product
> (this excludes bugs on chatzilla, etc; also excludes firefox-specific
> bugs, of course) that are "confirmed" (that is, not UNCONFIRMED). There
> are 12 more Core UNCONFIRMED bugs with the security flag set.
>
> Now of these bugs, a number should not be security-sensitive, imo (and
> in the opinion of Dan Veditz, who explicitly said as much in the
> comments on the ones that I looked at which looked particularly
> egregious). The number of actual open security issues in Core is likely
> much significantly lower than the "64" we have for confirmed
> security-sensitive bugs....
Do you consider a number significantly lower than 64 to be outside of a
"not a lot" categorization? I'm interested because I was just about to
reply to HJ with a post that was very nearly a cross between Gerv's post
and your post (before I'd read either of them) and it didn't seem
contradictory to me.
--Asa
Boris Zbarsky
> I don't believe that we have a lot of unsolved security bugs that are
> undisclosed.
[...]
> I don't think that what we currently have behind closed doors qualifies
> as "a lot" of untouched or unsolved security issues. You seem to agree
> in your next paragraphs, so what are you calling Gerv out on, exactly?
There are two separate numbers here.
1) The number of unsolved undisclosed security-sensitive bugs that correspond
to real security issues (exploits).
2) The number of unsolved undisclosed security-sensitive bugs that do NOT
correspond to real security issues (eg some of the "audit this code" bugs).
The first number is not so big, the bugs there are reasonably well-managed, and
so forth. The second number is far too large any time it's more than "the few
that got filed after the last time we went through the list". Ideally it should
be zero, because as far as I can tell, per our policy bugs in this category
should not be marked security-sensitive. One of HJ's complaints was about this
second category of bugs; that's the complaint I support. From a brief look,
some of the bugs in this category have been untouched for years. Keeping them
closed is just counter-productive.
> Do you consider a number significantly lower than 64 to be outside of a
> "not a lot" categorization?
This is the first number of the two numbers above. I'm having issues with the
second one.
-Boris
HJ
> Boris Zbarsky wrote:
>
>> Gervase Markham wrote:
>>
>>>> The Mozilla Foundation makes it virtually impossible for people to
>>>> fix security related bugs, because this kind of bugs are
>>>> 'undisclosed' for them, and there are still a lot of them
>>>> untouched/unsolved!
>>>
>>> How do you know there are still a lot unsolved if they are undisclosed?
>>
>> Gerv, I'm frankly quite surprised you'd make a specious argument like
>> this.
>
>
> I don't believe that we have a lot of unsolved security bugs that are
> undisclosed.
>
> I think I'd describe our unsolved security-related bugs as a fairly
> manageable list and something reasonably less than "a lot".
Asa, I'm fully aware of the fact that you like/need to defend this, but
please re-read my comment first and note that the "a lot" part was
refering to "this kind of bugs" i.e. security related bugs, not about
the *number* of unsolved security related bugs.
HJ
Right, that's exactly what I was after...the second category!
Thanks Boris,
/HJ
Gervase Markham
>> How do you know there are still a lot unsolved if they are undisclosed?
>
> Gerv, I'm frankly quite surprised you'd make a specious argument like
> this.
Well, it wasn't an argument, it was a question. "Boris told me" would
have been one among many valid answers.
Gerv
Gervase Markham
> and scroll down to: 4. DISCLAIMER OF WARRANTY...
> and note the "SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR
> LIMITATION OF IMPLIED WARRANTIES, SO THIS DISCLAIMER MAY NOT APPLY TO YOU."
>
> Scroll down to: 5. LIMITATION OF LIABILITY...
> and note the "SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR
> LIMITATION OF INCIDENTAL, CONSEQUENTIAL OR SPECIAL DAMAGES, SO THIS
> EXCLUSION AND LIMITATION MAY NOT APPLY TO YOU."
>
> Shit happens you know, just a matter of time, and I don't want to wait
> ill prepared.
You didn't ship Firefox, so you are not liable for security holes in it.
And legally, the situation where you personally do not know about a
vulnerability (and so can't do anything about it) is the same as if
no-one knows about it, so you as an extension author are not at greater
legal risk by not knowing about such vulnerabilities.
Gerv
HJ
> HJ wrote:
>
>> and scroll down to: 4. DISCLAIMER OF WARRANTY...
>> and note the "SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR
>> LIMITATION OF IMPLIED WARRANTIES, SO THIS DISCLAIMER MAY NOT APPLY TO
>> YOU."
>>
>> Scroll down to: 5. LIMITATION OF LIABILITY...
>> and note the "SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR
>> LIMITATION OF INCIDENTAL, CONSEQUENTIAL OR SPECIAL DAMAGES, SO THIS
>> EXCLUSION AND LIMITATION MAY NOT APPLY TO YOU."
>>
>> Shit happens you know, just a matter of time, and I don't want to wait
>> ill prepared.
>
>
> You didn't ship Firefox, so you are not liable for security holes in it.
Correct, but 'we' the extension writers *are* liable for security holes
in our extensions, which of some could have been fixed by us, if we only
knew what is going on.
Also, I received a short but clear e-mail from someone living in Germany
stating that this Mozilla Firefox EULA, but I don't remember if it was
limited to point 4 or 5 or the both of them, but anyway, one or both
points can be considerd 'invalid' for people living in Germany, and
there are other countries with the same limitation so that doesn't help
me nor the mozilla foundation.
p.s. do you have a link to the EULA for Mozilla (if there is one for
Mozilla)?
> And legally, the situation where you personally do not know about a
> vulnerability (and so can't do anything about it) is the same as if
> no-one knows about it, so you as an extension author are not at greater
> legal risk by not knowing about such vulnerabilities.
>
> Gerv
The problem is that *I know* about these vulnerability but I don't get
'official' access to these bug reports, to either help or fix it in my
extensions only, and that's what worries me, and should worry others as
well.
/HJ
HJ
Just for the record, Boris didn't tell me anything, not even a single
number or bug count, before I posted my complaint, however, he did
mention this kind of information *after* my complaint in this newsgroup,
and that was sort of a confirmation for me!
/HJ
Gervase Markham
> Correct, but 'we' the extension writers *are* liable for security holes
> in our extensions, which of some could have been fixed by us, if we only
> knew what is going on.
Yes, but you are equally liable (or not liable) in the situations
"Someone else knows, but we don't", and "No-one knows".
If there is a security hole in your extension specifically, you'd be
informed. But there's no way we can let everyone who writes an extension
see all the security bugs, in case there's some impact on code in their
extension.
> Also, I received a short but clear e-mail from someone living in Germany
> stating that this Mozilla Firefox EULA, but I don't remember if it was
> limited to point 4 or 5 or the both of them, but anyway, one or both
> points can be considerd 'invalid' for people living in Germany, and
> there are other countries with the same limitation so that doesn't help
> me nor the mozilla foundation.
What has this to do with security bugs?
> p.s. do you have a link to the EULA for Mozilla (if there is one for
> Mozilla)?
There isn't one for Mozilla. Mozilla binaries that the Foundation
distributes are distributed under the MPL.
> The problem is that *I know* about these vulnerability but I don't get
> 'official' access to these bug reports, to either help or fix it in my
> extensions only, and that's what worries me, and should worry others as
> well.
If you know about a vulnerability but don't have access to the bug
report about it, you can file a new security-sensitive bug about it.
This would then get marked as a duplicate, and you'd get auto-CCed on
the original. If it's not a duplicate, then you've discovered a new
security bug.
Gerv
Simon Paquet
> If there is a security hole in your extension specifically, you'd
> be informed. But there's no way we can let everyone who writes an
> extension see all the security bugs, in case there's some impact
> on code in their extension.
And why is that? Why do we not adopt a full disclosure policy? The
current security policy was written in the old Netscape days, when
Netscape still ruled the Mozilla project and was anxious about
security issues in its products.
The more I think of it and the more I hear of it, the less I'm convinced
that our current security policy is a good thing.
>> The problem is that *I know* about these vulnerability but I don't
>> get 'official' access to these bug reports, to either help or fix
>> it in my extensions only, and that's what worries me, and should
>> worry others as well.
>
> If you know about a vulnerability but don't have access to the bug
> report about it, you can file a new security-sensitive bug about it.
> This would then get marked as a duplicate, and you'd get auto-CCed on
> the original. If it's not a duplicate, then you've discovered a new
> security bug.
So you're proposing that people in the know clutter bugzilla with
useless duplicate bug reports just to get access to the real security
bugs? That doesn't strike me as a very sound idea.
--
Simon Paquet
James Graham
> HJ wrote:
>
>> The problem is that *I know* about these vulnerability but I don't get
>> 'official' access to these bug reports, to either help or fix it in my
>> extensions only, and that's what worries me, and should worry others
>> as well.
>
>
> If you know about a vulnerability but don't have access to the bug
> report about it, you can file a new security-sensitive bug about it.
> This would then get marked as a duplicate, and you'd get auto-CCed on
> the original. If it's not a duplicate, then you've discovered a new
> security bug.
Right but a diligent extension author might be watching bonsai looking
for security related checkins. They might see a 'suspicious' change but
have no access to the bug report to understand the reasoning behind the
change and what, if anything, they need to do to protect their users (in
cases where the change they need to make isn't obvious). I'm not sure if
security-sensitive bugs are supposed to be opened up after a patch has
been checked in but this doesn't happen and so there is a problem.
HJ
> HJ wrote:
>
>> Correct, but 'we' the extension writers *are* liable for security
>> holes in our extensions, which of some could have been fixed by us, if
>> we only knew what is going on.
>
>
> Yes, but you are equally liable (or not liable) in the situations
> "Someone else knows, but we don't", and "No-one knows".
In that case, does it make the Mozilla Foundation look good? I don't
think so. I also think that you are missing the bigger picture of all
this, because people that develop products based on Mozilla.org products
*are* in fact left in the dark, sometimes for way too long, but this
doesn't happen when they, me in this case, use Microsoft products,
because they offer me help, and you don't!
> If there is a security hole in your extension specifically, you'd be
> informed. But there's no way we can let everyone who writes an extension
> see all the security bugs, in case there's some impact on code in their
> extension.
I've never been notified of one, but I helped fixing security related
bugs before, and I speak out when I find one, but I don't need no money
for it, because I don't care about money.
Gerv, you don't have a clue about the number of secret projects I work
on, so you, nor anybody else for that matter, will ever see any of them
without a level 5 clearance.
>> Also, I received a short but clear e-mail from someone living in
>> Germany stating that this Mozilla Firefox EULA, but I don't remember
>> if it was limited to point 4 or 5 or the both of them, but anyway, one
>> or both points can be considerd 'invalid' for people living in
>> Germany, and there are other countries with the same limitation so
>> that doesn't help me nor the mozilla foundation.
>
>
> What has this to do with security bugs?
Extension writers have a responsibility towards their customers/end
users and so do you and the Mozilla Foundation, again, this EULA is
invalid in countries that use my products, for example in Germany, so
guess who's going to pay the price, and that's not me!
>> p.s. do you have a link to the EULA for Mozilla (if there is one for
>> Mozilla)?
>
>
> There isn't one for Mozilla. Mozilla binaries that the Foundation
> distributes are distributed under the MPL.
That is what I expected, thanks for this confirmation.
>> The problem is that *I know* about these vulnerability but I don't get
>> 'official' access to these bug reports, to either help or fix it in my
>> extensions only, and that's what worries me, and should worry others
>> as well.
>
>
> If you know about a vulnerability but don't have access to the bug
> report about it, you can file a new security-sensitive bug about it.
> This would then get marked as a duplicate, and you'd get auto-CCed on
> the original. If it's not a duplicate, then you've discovered a new
> security bug.
>
> Gerv
No, I don't want to add more clutter to the already cluttered bugzilla
database because that way more bugs will be left alone for too long.
/HJ
Justin Wood (Callek)
> Gervase Markham wrote:
>> If you know about a vulnerability but don't have access to the bug
>> report about it, you can file a new security-sensitive bug about it.
>> This would then get marked as a duplicate, and you'd get auto-CCed on
>> the original. If it's not a duplicate, then you've discovered a new
>> security bug.
>>
>> Gerv
>
>
> No, I don't want to add more clutter to the already cluttered bugzilla
> database because that way more bugs will be left alone for too long.
>
> /HJ
Even though I disagree with gerv on his point here, (though my
disagreement reasoning has already been stated and beaten to death)
I feel I must play devil's advocate here, HJ...
It has also been already stated that the security group bugs are triaged
quickly, and as such a "Duplicate" is marked as such quickly, (and thus
resolved), and a new bug is left as a new bug...and thus "A bug they now
know about".
With the current security policy Gerv's suggestion is the best one,
(unless you can convince then to give yourself clearance to Mozilla's
security Bug-pool)
~Justin Wood, (Callek)
HJ
> HJ wrote:
>
>> Gervase Markham wrote:
>>
>>> If you know about a vulnerability but don't have access to the bug
>>> report about it, you can file a new security-sensitive bug about it.
>>> This would then get marked as a duplicate, and you'd get auto-CCed on
>>> the original. If it's not a duplicate, then you've discovered a new
>>> security bug.
>>>
>>> Gerv
>>
>> No, I don't want to add more clutter to the already cluttered bugzilla
>> database because that way more bugs will be left alone for too long.
>>
>> /HJ
>
> Even though I disagree with gerv on his point here, (though my
> disagreement reasoning has already been stated and beaten to death)
>
> I feel I must play devil's advocate here, HJ...
No worries, I'm a fairly reasonable person ;)
> It has also been already stated that the security group bugs are triaged
> quickly, and as such a "Duplicate" is marked as such quickly, (and thus
> resolved), and a new bug is left as a new bug...and thus "A bug they now
> know about".
>
> With the current security policy Gerv's suggestion is the best one,
> (unless you can convince then to give yourself clearance to Mozilla's
> security Bug-pool)
>
> ~Justin Wood, (Callek)
Thanks Justin, I noticed that I'm fighting a lost battle once
again...however, maybe I reconsider, and go claim my 51.000 dollar
bounty one day for finding security bugs :-)
/HJ
Daniel Veditz
> With the emphasis on security, perhaps it's necessary for Firefox once a
> week (or 2) to contact UMO and check latest plugin versions. So that we
> can prompt "Plugin XXX has been updated".
It's supposed to, but a bug in 1.0 meant it only checked the first week
of every month.
Or did you really mean plugins rather than extensions? We do plan on
having the update checks cover plugins in some fashion as well for 1.1
> This is more intiuitive to the user, and gets everyone. I'm curious how
> many still use the Firefox start page. I'd bet not that many.
Sure, that'd be better, but we have a problem with old JRE's *NOW*.
There just wasn't enough time to build up a new service and squeeze it
into 1.0.1, spreading the word as wide as we can is about the best we
can do.
-Dan Veditz
Daniel Veditz
> Btw, there's this bounty program for (serious) security bugs, but who
> determines if a bug is 'serious' or not? Also, I never read anything, or
https://bugzilla.mozilla.org/show_bug.cgi?id=256197
Please treat that bug as read-only. I will quickly hide it if it starts
to become useless as a tracking tool.
We have not yet met to award bounties for more recent flaws. When we do
I will update that bug, and there will be some sort of press release
about it.
Daniel Veditz
> 2005-02-14 - Summary of mozilla.org staff meeting
> -------------------------------------------------
> - dveditz was employed a year ago to focus on security
I have to correct this: I was hired as an employee just last month,
January 2005. I started contracting for the foundation August 2004 --
about half as long as the minutes state.
-Dan Veditz
Daniel Veditz
> Gervase Markham wrote:
>
>> HJ wrote:
>>
>>> Also, how can extension writers, people like me, get a handle on
>>> security issues, before they are fixed and made public?
>>
>> What sort of security issues do you need to know about?
>
> Well, for example, any changes in chrome javascript for security
> reasons, (many extensions, particularly large ones will replace bits of
> chrome code with their own version), changes to best practice (if there
> was any clearly documented best practice to begin with) when using
> certian objects, that sort of thing.
I would love to notify extension authors about this kind of thing.
Merely un-hiding the bug isn't going to do it, it will get lost in the
thousands of other bugs we have. How do I make sure the right people
hear about the problem?
Is there an existing mailing list or newsgroup that would cover the
right audience? Should I just mail to all the authors who have addresses
on file with UMO (rhetorical, obviously that misses a lot of people)?
Set up a new mailing list?
-Dan Veditz
Justin Wood (Callek)
Even as a Mozilla "Hacker" who barely touches UI stuff, this would be
helpful. Incase there is a chance I want/need to touch something UI
related, knowing of changes relating to what I "used to know" is great.
Personally a new mailing list/NG would be good enough for me. And then
some of the existing Venue's for Extension Authors can find out about
the Mailing list and opt-in if they feel a desire to keep up on this stuff.
New users to UMO and Mozdev could then also be notified of this List,
(granted Mozilla Foundation cannot controll what Mozdev does, but still)
Just my few comments from a current, non-extension writer, and a person
who hardly touches anything UI.
~Justin Wood (Callek)
Simon Paquet
>> Well, for example, any changes in chrome javascript for security
>> reasons, (many extensions, particularly large ones will replace bits of
>> chrome code with their own version), changes to best practice (if there
>> was any clearly documented best practice to begin with) when using
>> certian objects, that sort of thing.
>
>I would love to notify extension authors about this kind of thing.
>Merely un-hiding the bug isn't going to do it, it will get lost in the
>thousands of other bugs we have. How do I make sure the right people
>hear about the problem?
>
>Is there an existing mailing list or newsgroup that would cover the
>right audience? Should I just mail to all the authors who have addresses
>on file with UMO (rhetorical, obviously that misses a lot of people)?
>Set up a new mailing list?
Some kind of a mozilla-security-announce mailing list would be great.
Simon
--
Default QA Contact Firefox - Menus/Toolbars/Installer
My Mozilla blog: http://www.babylonsounds.com/blog.html
Join us on Bugday: Every Tuesday from 10 AM - 6 PM PST in the
#mozillazine channel on irc.mozilla.org
Gervase Markham
> Right but a diligent extension author might be watching bonsai looking
> for security related checkins. They might see a 'suspicious' change but
> have no access to the bug report to understand the reasoning behind the
> change and what, if anything, they need to do to protect their users (in
> cases where the change they need to make isn't obvious). I'm not sure if
> security-sensitive bugs are supposed to be opened up after a patch has
> been checked in but this doesn't happen and so there is a problem.
If it doesn't happen (at least within a couple of days), then there is
indeed a problem, and you should complain to security-group at mozilla.org.
Gerv
Gervase Markham
> I have to correct this: I was hired as an employee just last month,
> January 2005. I started contracting for the foundation August 2004 --
> about half as long as the minutes state.
s/the minutes state/chofmann, in the meeting, stated/ :-)
Gerv
James Graham
> James Graham wrote:
>>
>> reasons, (many extensions, particularly large ones will replace bits
>> of chrome code with their own version), changes to best practice (if
>> there was any clearly documented best practice to begin with) when
>> using certian objects, that sort of thing.
>
>
> I would love to notify extension authors about this kind of thing.
> Merely un-hiding the bug isn't going to do it, it will get lost in the
> thousands of other bugs we have. How do I make sure the right people
> hear about the problem?
> Set up a new mailing list?
A new mailing list sounds ideal. I suppose the easiest solution is
simply to have, as has already been suggested, a
mozilla-security-announce list that covers *all* security issues and
provide additional information for extension authors where necessary.
Possibly UMO should auto-subscribe people to this list when they first
submit an extension.
Boris Zbarsky
> James Graham wrote:
>> opened up after a patch has been checked in but this doesn't happen
>> and so there is a problem.
>
> If it doesn't happen (at least within a couple of days), then there is
> indeed a problem, and you should complain to security-group at mozilla.org.
mozilla.org policy used to be that security bugs are opened up once the "major
vendor branches" have shipped releases with fixes. In the past this has meant
that Netscape, Compuserve, and SeaMonkey stable releases were all shipped with
the change. I'm not sure what counts as a "major vendor branch" nowadays, but
based on what bugs are and are not opened and when, it's looking like Firefox
does. Not clear about SeaMonkey, nor about vendor (RedHat, e.g.) releases of
Firefox (which end up with the same general issue as extension developers, by
the way, see Chris Aillon's previous complaints on the subject).
Given this policy, I can think of very few cases when a bug is opened up "within
a couple of days" of the fix being checked in, even in the best case. Based on
past experience, it will typically get opened up a few weeks after the "major
vendor branches" have shipped, if someone remembers to do it.
-Boris
Michael Lefevre
> James Graham wrote:
>> I'm not sure if
>> security-sensitive bugs are supposed to be opened up after a patch has
>> been checked in but this doesn't happen and so there is a problem.
>
> If it doesn't happen (at least within a couple of days), then there is
> indeed a problem, and you should complain to security-group at mozilla.org.
If the security-group folks aren't aware that this happens often, then
we need a new security group :)
Bugs are (AIUI) opened up after the next release happens (and dveditz
seems to have actually managed to do this within a reasonable time of the
recent releases - it didn't happen for the first part of 2004) - if they
were opened up after the checkin, then some of the Firefox 1.0 issues
would have been opened up in January, long before fixes were available in
1.0.1.
--
Michael
Gervase Markham
> Given this policy, I can think of very few cases when a bug is opened up
> "within a couple of days" of the fix being checked in, even in the best
> case. Based on past experience, it will typically get opened up a few
> weeks after the "major vendor branches" have shipped, if someone
> remembers to do it.
Maybe I'm confusing it with the Bugzilla policy, where we batch fixes
and check them in just before the release, to avoid giving the bad guys
a head start.
Could this be a useful approach for Firefox also, or is too much testing
required in most cases?
Gerv
Gervase Markham
> And why is that? Why do we not adopt a full disclosure policy? The
> current security policy was written in the old Netscape days, when
> Netscape still ruled the Mozilla project and was anxious about
> security issues in its products.
Frank Hecker has recently written about the current security policy, why
it was implemented originally, and why it's still a good idea:
http://www.hecker.org/mozilla/full-disclosure
>> If you know about a vulnerability but don't have access to the bug
>> report about it, you can file a new security-sensitive bug about it.
>> This would then get marked as a duplicate, and you'd get auto-CCed on
>> the original. If it's not a duplicate, then you've discovered a new
>> security bug.
>
> So you're proposing that people in the know clutter bugzilla with
> useless duplicate bug reports just to get access to the real security
> bugs? That doesn't strike me as a very sound idea.
What do you mean by "people in the know"? If you know about a bug and
know that it's filed, why do you need access to the bug report if you
haven't got it already? If you want to help fix it, a mail to
securit...@mozilla.org saying "I know you have a bug about X on
file, and I have a patch - can someone please CC me?" will probably get
results, depending on who you are and whether you are trusted.
On the other hand, if you don't know if a bug has been filed, you should
be filing it in case it hasn't.
Gerv
Gervase Markham
> And why is that? Why do we not adopt a full disclosure policy? The
> current security policy was written in the old Netscape days, when
> Netscape still ruled the Mozilla project and was anxious about
> security issues in its products.
Frank Hecker has recently written about the current security policy, why
it was implemented originally, and why it's still a good idea:
http://www.hecker.org/mozilla/full-disclosure
>> If you know about a vulnerability but don't have access to the bug
>> report about it, you can file a new security-sensitive bug about it.
>> This would then get marked as a duplicate, and you'd get auto-CCed on
>> the original. If it's not a duplicate, then you've discovered a new
>> security bug.
>
> So you're proposing that people in the know clutter bugzilla with
> useless duplicate bug reports just to get access to the real security
> bugs? That doesn't strike me as a very sound idea.
What do you mean by "people in the know"? If you know about a bug and
Gervase Markham
> Given this policy, I can think of very few cases when a bug is opened up
> "within a couple of days" of the fix being checked in, even in the best
> case. Based on past experience, it will typically get opened up a few
> weeks after the "major vendor branches" have shipped, if someone
> remembers to do it.
Maybe I'm confusing it with the Bugzilla policy, where we batch fixes
Boris Zbarsky
> What do you mean by "people in the know"?
How about "anyone watching bonsai"?
> If you know about a bug and
> know that it's filed, why do you need access to the bug report if you
> haven't got it already?
Because I saw a fix go in for it, the fix makes no sense to me, I need to
evaluate whether I have similar issues in my extension or embedding app, and I'd
like to read the bug to see whether the comments there make it clearer what the
fix is doing. As it is, all I know is that there is a critical security issue
and this code change that doesn't make sense to me fixes it.
> If you want to help fix it
Again, consider an embeddor who sees a Firefox change land that may require
porting to the embeddor's app... Not everyone who cares about our fixes for
security bugs is necessarily interested in fixing said bugs.
-Boris
Boris Zbarsky
> Maybe I'm confusing it with the Bugzilla policy, where we batch fixes
> and check them in just before the release, to avoid giving the bad guys
> a head start.
>
> Could this be a useful approach for Firefox also, or is too much testing
> required in most cases?
The latter, for anything resembling a security change. Too much change of
either breaking content that depends on the insecure behavior or making the new
behavior too secure and breaking perfectly valid content.
Note that Bugzilla doesn't have these issues, since it doesn't really need to
interoperate with anything.
-Boris
Gervase Markham
> Because I saw a fix go in for it, the fix makes no sense to me, I need
> to evaluate whether I have similar issues in my extension or embedding
> app, and I'd like to read the bug to see whether the comments there make
> it clearer what the fix is doing. As it is, all I know is that there is
> a critical security issue and this code change that doesn't make sense
> to me fixes it.
Hmm. OK. I've been operating under the impression that fixes and bug
openings are pretty close to each other, when in fact they aren't.
So what can we do about that? We should have a mailing list for security
checkins (not to do so is security by obscurity, and people want to
know), but what should the announcement say? There's a fine line between
helping people fix their code and giving enough detail to make exploit
easier.
Gerv
Adam Hauner
> So what can we do about that? We should have a mailing list for security
> checkins (not to do so is security by obscurity, and people want to
> know), but what should the announcement say? There's a fine line between
> helping people fix their code and giving enough detail to make exploit
> easier.
Look at
<http://www.mozilla.org/projects/security/known-vulnerabilities.html#Firefox>
and open several MFSA's for Fx 1.0.1. You'll see several times, that
described security bug is fixed in Firefox 1.0.1 and Mozilla Suite 1.7.6.
Actually there are not any 1.7.6 release of Suite yet, futhermore there
are several L10N versions of Firefox 1.0.1 including, which were not
released yet too (by MF own decision - from my point of view). So there
are many people using Mozilla applications with known security bugs,
which can't upgrade their product, and bad guys with full info.
So - where is fine line in this situation?
--
Adam Hauner
Boris Zbarsky
> So what can we do about that? We should have a mailing list for security
> checkins (not to do so is security by obscurity, and people want to
> know), but what should the announcement say? There's a fine line between
> helping people fix their code and giving enough detail to make exploit
> easier.
Yeah, it's a problem.... If we have a somewhat restricted list for these
postings that makes things simpler, but I can't think of reasonable criteria for
inclusion of people in the list.
If it's a fully public list, I _think_ that for most security bugs we could
write a toplevel description of the problem such that someone who reads the code
can figure out what is going on without posting ready-to-use exploits or
anything like that (which is what security bugs often have). I'm not sure how
that would fit in with the security policy, though.
-Boris