Archive Security Audits
Discuss how to better manage the influx of potentially insecure packages/changes into the devel archive.
Blueprint information
- Status:
- Not started
- Approver:
- Jamie Strandboge
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Discussion
- Series goal:
- Accepted for oneiric
- Implementation:
- Informational
- Milestone target:
- ubuntu-11.10
- Started by
- Completed by
Whiteboard
Agenda:
* Describe what comes in and how
* devel
* source NEW (non-Ubuntu devs, Debian, Ubuntu devs)
* binary NEW (syncs, new upsream)
* -security
* -proposed
* -updates
* -backports
* ppas (not official buildds are native and most ppas are virtual (the few ppas that are native have acls for Canonical)
* everything coming in is signed and has an LP acl
* it is relatively easy to identify and revert uploads from compromised account
* Known problems
* PPAs: complete trust in individual/teams (ie, typically no peer review) (but signed)
* vetting process for teams is varied
* -updates/-proposed
* lots of people can upload
* uploads are not built without human review
* uploads not published to -updates without human review/testing
* -security
* ppas limited to team
* publication is straight to users
* publication to pocket limited to team and a few other teams
* devel
* lots of people can upload (~180)
* lots of changes coming in
* MIR provide relatively high level review
* REVU provides review for non-Ubuntu devs
* ubuntu-archive provides packaging/licensing review of source NEW
* several high value targets
* Ideas for addressing the problems and automation (create debdiffs from the changes list and email to security? LP emails?)
* changes (soyuz)
* diffstat
* hotlink to debdiff
* verify link to the package version in LP
* UDD won't help
* doesn't show true state of the package archive
* autos-syncs don't show up on changes list
* 2-factor authentication for high-value targets
* Documentation ideas
* how system works
* how to handle keys
* ...
* look at changes mailing list/local mirror changes and generate:
* reports of what changed
* links to debdiffs
* static analysis of changes
* create a weekly role to review the reports?
* do a debcompare
* Why do this at all?
* spectrum of potential things we could catch:
* accidental dropping of patches
* malicious
* idea of who uploads what
* understanding of what's happening in Ubuntu
* bugs claimed to be fixed are what was fixed
* maybe fetch title of the bug that is in the email
* compare-log type report
* what to look for:
* main packages
* who uploaded what package and if it makes sense (show last 5-10 uploaders)
* diffstat/debdiff doesn't match description
* security features turned off
* new policy kit rights
* compare-bin
* last 5 uploaders of the package
* compare-log type report
* dealing with new uhttps:
Also see https:/