not possible for ubuntu-sru team member to use sru-remove

[Brian Murray]

I received the following Traceback when trying to remove a package from -proposed.

 $ ./sru-remove -s xenial -p golang-go.crypto 1634609
Removing packages from xenial-proposed:
        golang-go.crypto 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial
                golang-go.crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial amd64
                golang-go.crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial arm64
                golang-go.crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial armhf
                golang-go.crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial i386
                golang-go.crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial powerpc
                golang-go.crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial ppc64el
                golang-go.crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial s390x
                golang-golang-x-crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial amd64
                golang-golang-x-crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial arm64
                golang-golang-x-crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial armhf
                golang-golang-x-crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial i386
                golang-golang-x-crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial powerpc
                golang-golang-x-crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial ppc64el
                golang-golang-x-crypto-dev 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1 in xenial s390x
Comment: The package was removed due to its SRU bug(s) not being verified in a timely fashion.
Traceback (most recent call last):
  File "./remove-package", line 136, in <module>
    main()
  File "./remove-package", line 132, in main
    remove_package(options, args)
  File "./remove-package", line 79, in remove_package
    removal_comment=options.removal_comment)
  File "/usr/lib/python2.7/dist-packages/lazr/restfulclient/resource.py", line 607, in __call__
    extra_headers=extra_headers)
  File "/usr/lib/python2.7/dist-packages/lazr/restfulclient/_browser.py", line 431, in _request
    raise error
lazr.restfulclient.errors.Unauthorized: HTTP Error 401: Unauthorized
Response headers:
---
-content-encoding: gzip
content-length: 93
content-type: text/plain
date: Thu, 28 Sep 2017 15:12:14 GMT
server: zope.server.http (HTTP)
status: 401
strict-transport-security: max-age=15552000
vary: Accept,Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-launchpad-revision: 18463
x-lazr-notifications: []
x-powered-by: Zope (www.zope.org), Python (www.python.org)
x-xss-protection: 1; mode=block
---
Response body:
---
(<SourcePackagePublishingHistory at 0x7f57a78caad0>, 'api_requestDeletion', 'launchpad.Edit')
---

ERROR: There was an error removing golang-go.crypto from xenial-proposed.

I believe this works for archive admins and that ubuntu-sru should be able to use requestDeletion.

[Adam Conrad (adconrad)]

The problem is that the granular permissions the SRU and Release teams have are based solely on the queue, and not the archive. Once a package is accepted, those queue permissions become irrelevant, and the archive admins own it.

I don't disagree with what would be the ultimate conclusion here, which is that finer-grained archive admin permissions per series and pocket would be desirable (though, there'd also need to be extra training/caution involved before handing people the ability to break things as spectacularly as incorrect deletions can), but I suspect it'd be quite an overhaul to retrofit that request into LP.

[Colin Watson (cjwatson)]

I don't think it would be a particularly large overhaul at all. xPPH.requestDeletion is an odd special case that goes through AppendArchive, which is otherwise only used by a few weird and/or legacy methods (Archive.syncSource[s], Archive.newSubscription, and Archive.removeCopyNotification). It would be quite easy to get it to check Archive.canAdministerQueue instead, if Ubuntu would be OK with that from a policy perspective. Doing that wouldn't affect any other methods.

The name of the "queue admin" archive permission type would indeed become a slight misnomer if we did that, but it's already called just "admin" in the edit-acl client tool, and I reckon the retcon of saying that it actually means admin privileges over the suite rather than just the queue associated with the suite would be a reasonable one to perform.

[Adam Conrad (adconrad)]

23:58 < infinity> cjwatson: Hrm, curious. And that would affect only deletions? Cause the next thing Brian will complain about is overrides probably (for phasing).
23:58 < infinity> cjwatson: Fundamentally, I'm not sure if this is a thing we want a broader group having rights to without sufficient training anyway, and with said training, they can just be full AA.