Non-admins cannot change PPA privacy after creation

Bug #1013313 reported by Jonathan Lange on 2012-06-14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself

Bug Description

Although anyone with a commercial subscription may *create* a private PPA, only commercial administrators and admins may change the 'private' attribute of a PPA. In particular, the creator of a private PPA may not make that PPA public without (commercial) admin intervention.

This is because the 'private' attribute of IArchive requires 'launchpad.Commercial' level permissions on the archive.

I do not think it appropriate to grant PPA owners who are commercial subscribers full launchpad.Commercial permissions, as these include the ability to set authorized_size, build_debug_symbols, buildd_secret, enabled_restricted_families, external_dependencies and require_virtualized, as well as private.

Some solutions occur to me:

 1. Make setting 'private' require only 'launchpad.Edit', and check for commercial subscriptions in the property.
 2. Create a new permission level meaning something like "I have paid for extra privileges", and have 'private' require that.
 3. Use the existing, strange permission 'launchpad.Special'.
 4. Move the current permissions granted by 'launchpad.Commercial' into a different permission level. Perhaps 'launchpad.Moderate'.

1 is essentially ignoring the Zope permission system. 2 has been deprecated in past conversations with the technical architect. 3 seems wrong. 4 is very high impact and rather risky.

How to reproduce the problem:

  from launchpadlib.launchpad import Launchpad
  import os

  APP_NAME = 'create-commercial-ppa'
  CACHE_DIR = os.path.expanduser('~/.launchpadlib/cache')
  LP_INSTANCE = 'production'

  lp = Launchpad.login_with(APP_NAME, LP_INSTANCE, CACHE_DIR, version="devel")
  jml = lp.people['jml']
  ppa = jml.getPPAByName(name='ca-tools')
  ppa.private = False

Produces the following output:
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python2.7/dist-packages/lazr/restfulclient/", line 732, in lp_save
      URI(self.self_link), representation, headers)
    File "/usr/lib/python2.7/dist-packages/lazr/restfulclient/", line 336, in patch
      'PATCH', extra_headers=extra_headers)
    File "/usr/lib/python2.7/dist-packages/lazr/restfulclient/", line 281, in _request
      raise error
  lazr.restfulclient.errors.Unauthorized: HTTP Error 401: Unauthorized
  Response headers:
  -content-encoding: gzip
  connection: close
  content-length: 60
  content-type: text/plain
  date: Thu, 14 Jun 2012 17:53:07 GMT
  server: zope.server.http (HTTP)
  status: 401
  strict-transport-security: max-age=2592000
  vary: Accept,Accept-Encoding
  via: 1.1
  x-content-type-options: nosniff
  x-frame-options: SAMEORIGIN
  x-lazr-notifications: []
  x-powered-by: Zope (, Python (
  x-xss-protection: 1; mode=block
  Response body:
  (<Archive at 0x13dcd110>, 'private', 'launchpad.Commercial')

Jonathan Lange (jml) on 2012-06-14
description: updated
Changed in launchpad:
status: New → Triaged
importance: Undecided → High
William Grant (wgrant) wrote :

Note that it's not currently possible for even an admin to change an archive's privacy once it's been used.

Jonathan Lange (jml) wrote :

Right. This bug is about changing privacy before use. IIUC, the reason Archive.private is a property rather than an attribute is precisely to enforce this restriction. The fact that it's already used to stop changes is why I lean slightly toward option 1, even though it would be adding another hack on to Launchpad's already dangerously-complex permission model.

Joey Stanford (joey) wrote :

me tooing for enabled_restricted_families since this is reason we have some PES folks in ~commercial-admins

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers