Security Community Improvement

Registered by Kees Cook

Discuss how to grow the Ubuntu Security Community

Blueprint information

Status:
Complete
Approver:
Jamie Strandboge
Priority:
Essential
Drafter:
Jamie Strandboge
Direction:
Approved
Assignee:
Jamie Strandboge
Definition:
Approved
Series goal:
Accepted for oneiric
Implementation:
Implemented
Milestone target:
milestone icon ubuntu-11.10
Started by
Jamie Strandboge
Completed by
Jamie Strandboge

Related branches

Sprints

Whiteboard

Work items for oneiric-alpha-2:
[dholbach] look at new documentation for where we should be linked in (filed bug 790544): DONE

Work items:
[jdstrand] fix bug 702005 (new packaging guide about dealing with security updates in stable): DONE
[jdstrand] review our documentation and compare with new packaging guide (it is task based with knowledge linked off it or simpler pages and workflow): DONE
[dholbach] look at pbuilder-dist and see if it uses -security and -updates (bug 781003): DONE
[jdstrand] develop process to create target CVEs for every couple weeks which the community role can use: DONE
[jdstrand] coordinate with dholbach on developer initiatives and create a weekly or monthly list of packages 10-15: DONE
[micahg] check on mozilla ppa updates aren't going to changes: DONE
[kees] add references to secure programming documentation off the security FAQ: DONE

INFO: ScottK mentioned opening a bug for the backports project if backports is affected by a security issue
INFO: Ignoring this for now as hypatia has moved: [hypatia] approach local universities to participate in auditing code
INFO: removed bug report links since they are already listed in the whiteboard and were showing up in jdstrand's work items even though his portion of those bugs was completed

From etherpad (http://summit.ubuntu.com/uds-o/meeting/security-o-community/):
Agenda:
 * review Tuesday
 * talk to community team about bottlenecks to contributing
  * few people mentioned specific items
  * others lump us others
 * documentation
  * [ACTION] dholbach to look at new documentation for where we should be linked in
  * [ACTION] jdstrand to fix bug 702005 (new packaging guide about dealing with security updates in stable). Simplified version?
  * [ACTION] jdstrand to review our documentation and compare with new packaging guide (it is task based with knowledge linked off it or simpler pages and workflow)
  * [ACTION] dholbach to look at pbuilder-dist and see if it uses -security and -updates (bug 781003): DONE
 * growth
  * [ACTION] hypatia to approach local universities to participate in auditing code
  * have target CVEs for every couple weeks
  * [ACTION] jdstrand to coordinate with dholbach on developer initiatives and create a weekly or monthly list of packages 10-15
* marking bugs as bite-sized and advertising (merges)
 * easy to patch
 * easy to test
 * http://people.canonical.com/~ubuntu-security/d2u/ is in harvest now, but is hard to find
* follow up with new contributors
 - private email to them with thanks and ask for feedback
* contributing to stable releases
 - what about diposable VMs or cloud
* motivations
 - like fixing things all over
 - Debian developers
  - we should make sure that we do everything we can to help them get their changes
* [ACTION] micah to check on mozilla ppa updates aren't going to changes
* talks at DEFCON, conferences or others on how we deal with security updates
 * what we do
 * how we do it
 * we want people to contribute
* local security user groups (ITC security management stuff)
 * hackathon - in person or online
* openhatch
 * they reach out and have something like a patch pilot
 * forums
 * blogs
= patch piloting =
we should look at the list of 2000 bugs and look at the newest ones
harvest gedit (shows opportunities for other bugs)
== Tuesday ==
=== Description ===
Discuss how to grow the Ubuntu Security Community.
=== Issues ===

    Security issues are well-discussed across distros and projects, so that isn't an issue. The issue is that security teams are overwhelmed with the numbers of security issues that need to be acted on. Some of them are issues with apps in Universe, they might be low priority, but they are issues that need attention.

    What kind of person is a prime candidate for contributing security patches? The design team has created "Personas" that represent different types of Ubuntu users. What kind of people might be candidates to contribute to security?

    people can submit patches

    people can provide testing

    help with triage

    review/anaylize patches

    help ubuntu-security-sponsors

    contribute apparmor policy

    help ensure selinux works

    work with tomoyo and smack

    Team blogs sometimes, but doesn't want to get word out about all of their little fixes . . . much of the work is about maintenance. Maintenance across all of the stable releases.

=== Points ===

    We have to test fixes and determine whether it has to be included into the release.

    Security issues are identified as bugs, new community members could be people who are packagers who can provide a .deb diff. Packaging skills are a prerquisite for those kinds of things.

    Community work could be focused on building out the testing suite

=== Actions ===

    add references to secure programming documentation off the security FAQ

=== Questions ===

    Do we have guidelines on programming securely? Could provide a list of references for secure programming techniques. (david wheeler secure programs page)

    We don't have such at the moment

    Access control policies of the team, and the community

    qa-regression-testing has filesystem perms/owner checks that we run on isos

    -security pocket can only be uploaded to by ubuntu-security

    -updates pocket only uploaded to by people who have LP upload rights, and goes through a review process (via SRU process)

    devel release has MIR process and protected by LP upload rights. session security-o-archive-audits will discuss how to improve this

    processes in place to revoke privileges and packages in the event of compromise of a developer

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.