Juju needs security contacts

[Clint Byrum]

As Juju's profile rises, so will scrutiny of its security issues.

Thus far, it has been fairly haphazard how security problems have been
fixed in Juju. In particular, we have been fairly bad at keeping security
bugs private while fixes are prepared for the various platforms where
juju is being shipped.

I'd like to hear everyone's thoughts on security disclosure procedures
and where we stand. I am a proponent of coordinated disclosure, although
with a very limited time frame after notification of interested parties.

I don't think we have the resources to set it up though. We would need
to implement a plan something like this:

* Define who is responsible for responding to issues. I would like to
  make sure we have at least two people, and at least one of those must
  be familiar with the Go code base.
* Put these people in a 'juju-security' team.
* Ask anybody reporting a security bug to open a private security bug
  on launchpad.
* Add anybody interested in embargoed security bugs in juju to join
  juju-security-tracking. (Lets keep it light and just play by the
  honor system until somebody asks us for some kind of legal agreement)
* On the opening of a security bug, we should commit to triaging these
  within one business day.
* If a bug is of higher importance than "Low", we should take it on
  ourselves to produce a patch ASAP. For Low priority security issues,
  the bug can be made public and the normal bug fix procedures used.
* Patches for private issues *must not* be pushed to launchpad
  branches. Keep the branches local and share patches with reviewers
  through other means. Attach patches to the private bug report when
  they are ready.
* Once the bug has a fix, subscribe juju-security-tracking
* After 7 days of juju-security-tracking, unless a compelling request
  has come in for more time, we disclose the vulnerability on our public
  mailing list and commit fixes to trunk.

The alternative is to simply patch and fix these *as fast as possible*
and not coordinate security releases with interested parties. That is
certainly simpler than the above. It still requires a commitment from
the dev team to respond quickly though. So the above list reduces to:


* Define who is responsible for responding to issues. I would like to
  make sure we have at least two people, and at least one of those must
  be familiar with the Go code base.
* Put these people in a 'juju-security' team.
* On the opening of a security bug, we should commit to triaging these
  within one business day.
* If a bug is of higher importance than "Low", we should take it on
  ourselves to produce a patch ASAP. For Low priority security issues,
  the bug can be made public and the normal bug fix procedures used.
* Patches for private issues *must not* be pushed to launchpad
  branches. Keep the branches local and share patches with reviewers
  through other means.
* Commit fixes to public branches and send notifications about security
  fix.