[07:16] cjwatson, for the 1024R to 4096R PPA signing key migration, we have generated replacement keys for all the affected PPAs and now want to force-republish them to get them dual-signed so that we can stop exposing the 1024R and expose the new 4096R key instead. [07:17] For force-republishing, we decided on using the 'mark-suite-dirty' script to incrementally mark the affected PPAs as dirty to get them republished. But the script requires the 'launchpad.Append' permission on the archive it is called to operate on. [07:18] And based on what I understood, only the PPA owner has that permission and not even the site-wide admins have it. [07:20] One possible way to work around the permission issue is to directly set the dirty suites of the affected archives in the database table, but that feels ugly. Do you know if there is an existing way to do this bulk operation? [07:22] There is the option of weakening the permission to allow site-wide admins to do it, but that feels a bit risky since the permission also allows uploading to the archive - though I believe that requires a GPG-signed upload signed with the owner's key? [07:22] *temporarily weaking [07:22] *temporarily weakening [07:24] guruprasad: Yeah, granting append on every archive to ~admins wouldn't be something I'd recommend - it would for example allow copying into the archive without a GPG key. I'd consider writing a one-off Python script and having IS run it. [07:25] And do the direct DB change in that script? [07:25] guruprasad: Or see if you can reasonably come up with a way to do it via garbo. [07:25] guruprasad: Yes. [07:25] Okay, this is helpful advice! Thanks! [07:26] guruprasad: garbo would probably be my first resort since it's often good for data migrations, but maybe there's a reason that's difficult here (this isn't exactly a typical data migration, and maybe it's hard to make the change idempotent). [07:28] I hadn't thought of garbo as an option at all and it makes a lot of sense to try it out. [07:29] The idempotency, I will need to figure out the details. The list of affected archives is fixed and final since all new archives of affected persons are dual-signed already. [07:30] So the garbo job could iterate over the affected archives in batches, mark them dirty and repeat the same in the next interval. [07:32] It would be great if the job can also check whether the archives marked dirty in the previous run do not have dirty suites any more, but I guess it is not strictly needed. [07:40] I am also wondering if it is simpler to expose a new API method called, say adminMarkSuitesDirty, that requires 'launchpad.Admin' to invoke and does the markSuiteDirty change? It feels ugly but avoids making any unnecessary changes to existing permissions [07:40] while also keeping the scope of the new permission and operation just to the 'mark suite dirty' operation. [07:42] Thanks again for your helpful inputs!