Plugins:PluginDirectory:2010-03-26

From MozillaWiki
Jump to: navigation, search

Agenda

Scheduling:

  • Does the week of the 12th give us enough time to complete the everything we need for launch?
    • Les: Probably not, and is this absolutely everything we need for launch? Honestly, I'd like to be pessimistic about the launch date rather than rush anything - especially since this is a security-driven project. Probably better to think in terms of a mid-to-late Q2 goal than a mid-April goal.
  • Will all parties involved be able to prioritize this project accordingly in order to get this all done for that date?
    • Les: I've been mostly heads down on another project for the last weeks, but hopefully can come up for air in the next week. I expect distractions ahead, though.

Web Dev

  • Best Security Practices:
    • Do we have the list (Chris Lyon was going to provide) of security basics?
      • Les: Michael Coates has been filing good security bugs that need addressing - are these bugs "it", or is there more?
    • What has been implemented and what needs to be done?
      • Les: Hoping to review the security review bugs starting next week.
    • Who should implement?
      • Les: Probably me.
    • How long will it take?
      • Les: Not sure, pending a close look at the bugs so far.
  • Passwords
    • Already changed admin and editor passwords.
      • Les: Thanks, Austin.
    • What about the blanket password for stage site?
      • Austin: I question the value of a shared password auth on stage. It inhibits community testing while providing little risk mitigation.
      • Les: Do we want this? Could be a matter of a simple IT bug to create an .htaccess / .htpasswd, unless we want LDAP passwords (ie. a less-simple IT bug)
    • Who owns this?
      • Les: Probably me.
  • Connections between Plugin Dir and Check:
    • How do add the ability to shut off the connection if data is compromised?
      • Les: Probably best to build something into the Plugin Check page that displays a "service not available" message if the Plugin Directory serves up an error.
    • What should be the fallback data (good data) if such a shutoff were needed?
      • Les: No fallback data; there should be an admin panic switch in the Plugin Directory to cut off the API and serve up errors.
    • How do we make sure that data is "good"?
      • Les: There is no way, as far as I know.
    • Who owns this?
      • Les: Probably me.
      • Austin: If plugindir is compromised, then the webheads should be taken offline. The plugin check page will show an error (already built). We will have to take it offline to do intrusion detection analysis. This is my guess, probably need input from security before we build this, but maybe there is nothing to build?
  • Notification system
    • Who should be notified when changes happen?
      • Les: A list would be nice; that, and/or I could look at building an admin tool and per-user preferences to manage who gets notifications
      • chofmann: maybe security@mozilla.org and maybe donner/qa to check out the change and validate content that will be served.
    • Who should be on the hook to confirm changes?
      • Les: Hopefully not me; would be nice to have someone security-minded and plugin-informed to keep on top of it. I can help build the tools, but would rather not also be the manager of the data.
      • chofmann: there have been ideas circulating to hire a plugin partner manager. this person would work with plugin partners on crash data we have related to plugins, keeping the plugin check data up to date, and proactively making sure plugins use the right api's and best practices for compatibility. we have a ton of potencial partners in this area.
      • maybe some model like we have for addons. trusted group of amo-admins/editors reviews addons before they are released from the sandbox
    • Who builds this into the directory?
      • Les: Probably me.
  • Auditing Tools (chofmann: this auditing stuff should just be treated as an extension/next steps of the notification system mentioned above.)
    • Need tools to be able to audit activity with Plugins.
    • Need to create logs in order to track activity.
      • Les: What I have in mind: create a log table that records all changes to public plugin metadata (eg. not sandboxes) by time, user, and action - and will save backups of plugin metadata between each major change to enable rollbacks.
    • File an IT ticket to audit past activity/current activity on PMO.
      • Les: What kind of information is wanted? ie. just need apache logs pulled, more?
    • How does QA fit into this in order to follow what should be tested, what has been tested, what as defined as good data?
    • Who owns this?
      • Les: Probably me - at least in terms of building audit tools going forward.
  • Scope and Requirements
    • Austin: are any of these notification and auditing features optional or are they all absolutely critical before we ship?
      • It's very easy to scope creep these topics
        • an audit trail is much easier to build then a versioned data recover system? Is logging username and action details sufficient?
      • It seems we've included every idea mentioned during last meeting
      • Is there a gradual release plan 1) (plugindir API only) 2) plugindir launch

Security

  • Plugin Directory
    • Should Security own this? If not, who does?
      • Les: Would be nice to have stakeholders from Security and Firefox devs involved with plugins giving feedback on the project, but it's probably a WebDev effort.
      • chofmann: see ideas about a plugin partner manager above.
    • If so, when does the hand off happen and who should lead this project?
      • Les: Probably me.

QA

  • Progress on test plan?
  • Concerns, issues?
    • Caching seems to be an issue; I make changes and don't see them reflected live in either the Plugin Directory or the Plugin Check pages
    • Still trying to wrap my head around all the use-cases and flows (Les's doc is really helpful, but I haven't yet covered most everything)

Roundtable

Les

  • I'll be in Mountain View, 4/5-4/9 - there's mention of a Brown Bag, but maybe there needs to be more of a planning meeting?
  • The probably-me's up there add up to potentially a lot of work (eg. more than 2 weeks), and I'll be distracted by travel and other projects getting started with Q2.
  • This project hasn't been my top priority, and has only gotten about 20% of my time in Q1.
  • It could use more attention, both from me and other possibly interested parties (eg. Security folks, Firefox devs dealing with plugins, vendors).
  • Is this thing really ready for primetime, even after the security bugs have been addressed? Need some 2nd opinions here.
    • This thing is really more of a concept app at present than a solid piece of infrastructure.
    • Is the anonymous crowdsourcing of plugin data and security tips actually a good idea?
      • ...or is it too obscure for anyone not already a vendor representative or directory editor anyway?
    • Does the plugin editing / sandbox workflow process make sense?
    • Needs better basic admin tools - eg. user admin, audit tools
  • To launch the updated Plugin Check by April 12, yet not fully launch the Plugin Directory:
    • Turn on LDAP passwords for staging *and* production, except for the read-only search API at http://plugins.mozilla.org/pfs/v2
    • Dogfood the Directory as a (semi-)private tool to update Plugin Check for now, until it's had more time in the oven.
    • Pull back from vendor invitations to the Directory, for now?
      • Unless we give them LDAP passwords, and trust them, and apologize for feeding them my dogfood :)
Retrieved from "https://wiki.mozilla.org/index.php?title=Plugins:PluginDirectory:2010-03-26&oldid=211224"