Security/Meetings/2011-06-22

From MozillaWiki
Jump to: navigation, search

Goals

We did well on the Security team's Q2 goals.

We should be aware of and supportive of the Platform team's Q3 goals:

  1. Realize Android as a top-tier supported platform alongside Windows, Mac, and Linux
    • Jesse asked Damon what this goal means. The biggest parts are getting consistent Tinderbox coverage and ensuring developers/testers who need Android development environments have them.
      • Hint: this means security team members can request Android devices.
    • Where do we have ARM-specific code that we might need to fuzz on ARM?
      • imelven: looked at some codecs (libtheora has arm specific files, for example)
    • What other things are on Android but not on Desktop?
      • Different GPUs?
    • can we use an emulator on a desktop? can we leverage the automated testing pool somehow? should we have an arm fuzzing pool somehow?
    • we are doing JS engine fuzzing on ARM but that's it so far
  2. Implement prioritized list of features required to support Web Apps (Joint with Product and Apps teams)
  3. Ship a new web developer tool prototype in a release
    • Jesse: Could we make a web developer tool that focuses on web site security?
      • dchan: mcoates and stephend team are working on a tool to perform selenium based security tests on mozilla domains.
      • apparently Firefox 5 broke selenium but no one told the release drivers before ship

Homework

Think of potential Q3 goals for the Security team, bring to next week's meeting for brainstorm session

Travel for Black Hat

  • Hotels will be booked assuming leaving Fri(?). You'll be able to change if you want to stay longer, e.g. for DEFCON
  • Please book your flights

Access to security-sensitive bugs

Background:

  • About 150 people have access to core-security bugs (including ~20 who aren't on the mailing list).
    • Mostly developers, testers, and managers
    • Fewer than a dozen who represent distros
  • Few people only have mail access (security-group@).
  • Having a single Bugzilla group with access to all client security bugs is problematic.
    • Risk of bad guys compromising someone's account and suddenly having access to known security bugs.

Ideas for making it possible to make the all-security-bugs group smaller:

  • Additional group with access to fixed bugs? (Distro maintainers & backporters)
  • Additional group with access to untriaged bugs?
  • Additional group with access to JavaScript Engine bugs?

Should we open up all the old [sg:low] bugs?

Security roadmap & feature pages

https://wiki.mozilla.org/Security/Roadmap has been created to capture large chunks of work and feed into https://wiki.mozilla.org/Features/Inbox and eventually into the "god lists" such as https://wiki.mozilla.org/Features/Platform

  • Lucas: feel free to create feature pages for things on the roadmap
  • Jesse: this list is out of sync with sg:want bugs :(
    • Lucas: it's ok if smaller bugs aren't listed on the roadmap

Status updates

  • ian - getting up to speed on what's going on with mobile - tracking master password work, webgl on mobile and upcoming web app work (not chromeless so far), patched a couple of small csp bugs, currently auditing WOFF (bug 552308)
  • dchan - F1 is now deuxdrop, TestPilot mobile review in progress
  • sid - created feature pages for several items on the privacy roadmap. created Tor Roadmap. concerned about Metrics team's desire to use telemetry infrastructure to collect more sensitive long-term profiling/tracking information.
  • jesse - discussions about OOM handling, firefox update and extension compatibility, root-cause analysis. lots of new bugs. fuzzed some upcoming patches (strong-parent, plugins-in-content).

Infiltration of teams

Sid continues to sit in with product team meetings.