Working from two main premises:

1. we need to prevent attack vectors on the infrastructure, and
2. we need to reduce the load on admins as much as possible,

I suggest the following.

Package repositories

• We only install packages from trustworthy repositories.
  • OK are
    • The official Debian and Ubuntu repositories, and
    • Self-built packages (apt.wikimedia.org and aptly)
  • Not OK are:
    • PPAs
    • other 3rd party repositories

Packagers effectively get root on our systems, as they could add a rootkit to the package, or upload an unsafe sshd version, and apt-get will happily install it

apt.wikimedia.org
We assume that whatever is good for production is also OK for Tool Labs.

aptly
We manage the aptly repository ourselves.

• Packages in aptly need to be built by tool labs admins
  • we cannot import .deb files from untrusted 3rd party sources

• Package source files need to come from a trusted source
  • a source file from a trusted source (i.e. backports), or
  • we build the debian source files ourselves
  • we cannot build .dcs files from untrusted 3rd party sources

• Packages need to be easy to update and build [on tools-packages, which has package_builder applied]
  • cowbuilder/pdebuild OK
  • fpm is OK
  • we need docs on where we do this and how

• We only package if strictly necessary
  • infrastructure packages
  • packages that should be available for effective development (e.g. composer or sbt)
  • not: python-*, lib*-perl, ..., which should just be installed with the available platform-specific package managers

• For each package, it should be clear who is responsible for keeping it up to date
  • for infrastructure packages, this should be one of the paid staffers

Looking at the current package list in aptly:

• jobutils_1.5_all - infra (jsub et al). Responsible: @coren
• libmediawiki-bot-perl_5.005006-1_all
• libstring-diff-perl_0.06-1_all
• pep8_1.4.6-1.1_all (copy from apt.wm.o)
• python-backports.ssl-match-hostname_3.4.0.2-1_all
• python-celery_3.0.20-1_all
• python-celery-with-redis_3.0-1_all
• python-flask_0.9-1_all
• python-flask-login_0.2.4-1_all
• python-flask-oauth_0.12-1_all
• python-nose_1.3.0-1_all
• python-sh_1.09.1~precise-1_all
• python-socketio-client_0.5.3-1_all
• python-unicodecsv_0.9.4-1_all
• python-uwsgi_1.9.13-1_all
• python-websocket-client_0.23.0-1_all
• python-wikitools_1.1.1-1_all
• sbt_0.12.3-0.1-build-001_all - widely(?) used build system for scala, unknown source?!
• tcl_8.6.0-1_all
• toollabs-webservice_0.1_all - infra, @yuvipanda
• tools-manifest_0.6_all - infra, @yuvipanda
• tools-webservice_0.1_all - infra, @yuvipanda
• libaprutil1_1.5.2-1_amd64
• libaprutil1-dbd-sqlite3_1.5.2-1_amd64
• libaprutil1-ldap_1.5.2-1_amd64
• libodbc1_2.2.14p2-5_amd64
• libonig2_5.9.1-1_amd64
• libxml2_2.9.0+dfsg1-4_amd64 -- no clue what these libs are required for?
• misctools_1.5_amd64 - infra, @coren
• odbcinst_2.2.14p2-5_amd64 - same as in ubuntu repo?
• odbcinst1debian2_2.2.14p2-5_amd64
• python-billiard_2.7.3.30-1_amd64
• python-coverage_3.6-1_amd64
• python-mwparserfromhell_0.3.3-1_amd64
• python-oursql_0.9.3.1-1_amd64
• python-sqlalchemy_0.8.1-1_amd64
• tcl8.6_8.6.0-1_amd64
• unixodbc_2.2.14p2-5_amd64
• tools-manifest_0.6_source - not a real package

So we are left with:

• jobutils_1.5_all - infra (jsub et al). Responsible: @coren
• sbt_0.12.3-0.1-build-001_all - widely(?) used build system for scala, unknown source?!
• toollabs-webservice_0.1_all - infra, @yuvipanda
• tools-manifest_0.6_all - infra, @yuvipanda
• tools-webservice_0.1_all - infra, @yuvipanda
• misctools_1.5_amd64 - infra, @coren

which looks a whole lot more maintainable to me.