tb approval for package importer robot account (LP: #524173)

Martin Pool mbp at canonical.com
Thu Jun 9 06:31:17 UTC 2011


On 9 June 2011 15:30, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Hello Martin,
>
> Martin Pool [2011-06-09 14:15 +1000]:
>>  * having the tb add this to the list of permitted uploaders for
>> /ubuntu (but not into ~core-dev)
>
> What does "/ubuntu" mean here? I. e. where should we add this bot?

Hi Martin,

I meant <https://launchpad.net/ubuntu/> and specifically the
'Uploaders' section of that page.  I am told there is an api client
script which can add people into it, when run by a member of
~tech-board.  If the tech board agrees with the proposal but doesn't
know about that script I will find or write one.

> Also, what's the role of https://launchpad.net/~ubuntu-branches here?
> I thought that was the team that owns all the auto-imports?

It was, but it will be going away within the next few days.  There was
a tech-board thread about 10 days ago where Francis discusses removing
them: it helps adding support for Ensemble formulas; it's crufty
inside Launchpad; and because Launchpad is trying to get away from
having hardcoded permissions and celebrities.

<https://lists.ubuntu.com/archives/technical-board/2011-May/000907.html>

>> Some reasonable concerns have been raised that this does not get as
>> much to a least-privilege setup as one could desire.   In particular:
>> the new account will be able to upload packages as well as write to
>> branches: Launchpad does not have separate ACLs for those actions at
>> present.
>
> It should be easy to ascertain that the bot doesn't actually do any
> dput or ftp'ing, so I'm not too concerned about this as long as it
> runs in a trusted environment in the DC.
>
> At some point we plan to do package builds from branches, so it seems
> to me that this separation will become smaller or nonexistent in the
> future.

Right.

> Once that works, how can we ensure that the bot doesn't
> "accidentally" create a branch which will cause a package build?

That's an interesting question.  Normally it should only be creating
revisions for already-published packages.  As an implementation detail
we could want some kind of safeguards to make sure it doesn't get into
a feedback loop of causing existing packages to be rebuild in either
the same archive or a different one.  One approach would be to
specifically blacklist revisions that come from this robot (for which
giving it its own identity can of course only help).  There might be
others.  Or, it may be that just the check that the package version
has not already been published and is targeted to the right pocket is
enough.

>> On both of these I think it's worth acknowledging that more should be
>> done in the future, but also that making the importer use its own
>> account and identity will be a step forward for security and not a
>> step back.
>
> I agree. James already has way more privileges, so it's not a
> regression.

Thanks.

Martin



More information about the technical-board mailing list