I resolve them INVALID if they are reallky support questions because they aren’t and weren’t bugs in Firefox. Of the bugs that I end up closing, a bunch of them probably should have been support questions in the first place. The older, 2012 bugs are mostly obsolete at this point, but I have caught a few that are still valid, and that are now categorized in a product and component that brought them to the notice of the developers who may already be working on similar issues. I answer some from the front of the queue and some from the tail end, which right now goes back to February 2012. When I started putting half an hour to an hour a day into this, the count was well over 500 bugs.
I have it on my todo list as “FFUntriaged”, so I think of it that way.
That is to bring down a specific number, the bugs filed for Firefox that are in the “Untriaged” component, where the last comment was by the person who reported the bug. Lately I’ve been working on a fairly arbitrary goal. Many people in QA and various engineering teams also keep watch over the incoming bugs so that problems are caught quickly, escalated appropriately, and stuff gets fixed and released as soon as possible.īut the incoming are just one thing among many. I keep an eye on the incoming bugs, which are still around 350-550 for any 24 hour period and peck away at those. Browse free.As some of you may know we have over 900,000 thousand bug reports in these days. We have notified the relevant law enforcement authorities about this incident, and may take additional steps based on the results of any further investigations.įor more details, please see our FAQ document. That’s why we publish security bugs once they’re no longer dangerous, and it’s why we’re writing a blog post about unauthorized access to our infrastructure. Openness, transparency, and security are all central to the Mozilla mission. In other words, we are making it harder for an attacker to break in, providing fewer opportunities to break in, and reducing the amount of information an attacker can get by breaking in. We are reducing the number of users with privileged access and limiting what each privileged user can do. As an immediate first step, all users with access to security-sensitive information have been required to change their passwords and use two-factor authentication. We are updating Bugzilla’s security practices to reduce the risk of future attacks of this type. The version of Firefox released on August 27 fixed all of the vulnerabilities that the attacker learned about and could have used to harm Firefox users. We have no indication that any other information obtained by the attacker has been used against Firefox users. We believe that the attacker used information from Bugzilla to exploit the vulnerability we patched on August 6. The account that the attacker broke into was shut down shortly after Mozilla discovered that it had been compromised. We are also making improvements to Bugzilla to ensure the security of our products, our developer community, and our users. Mozilla has conducted an investigation of this unauthorized access, and we have taken several actions to address the immediate threat. We believe they used that information to attack Firefox users. It is in the same spirit of openness that we are disclosing today that someone was able to steal security-sensitive information from Bugzilla. While most information in Bugzilla is public, Bugzilla restricts access to security-sensitive information, so that only certain privileged users can access it. It’s a tool for coordinating among our many contributors, and a focal point for community interactions.
The Bugzilla bug tracker is a major part of how we accomplish our mission of openness at Mozilla.
0 kommentar(er)
