P3A subscribers can obtain the buildd_secret

[William Grant]

Since users now hold launchpad.View over their subscribed P3As, they can add them as dependencies and fire off a build, easily obtaining the buildd secret for any subscribed archive. Revoking their subscription will then not be effective, as they can simply use the internal buildd credentials.

OEM Services currently use the buildd credentials for a mission critical system. However as of March 2011 they have prioritised (over the next 2-3 months) transitioning to regular subscribers rather than the use of the buildd_secret. This bug is deferred until they complete that transition : check with them at the end of May 2011 to confirm they are no longer using the buildd secret.

[Julian Edwards (julian-edwards)]

On Friday 25 February 2011 20:19:05 Robert Collins wrote:

> + OEM Services currently use the buildd credentials for a mission critical
> + system. However as of March 2011 they have prioritised (over the next
> + 2-3 months) transitioning to regular subscribers rather than the use of
> + the buildd_secret. This bug is deferred until they complete that
> + transition : check with them at the end of May 2011 to confirm they are
> + no longer using the buildd secret.

Rob, this bug is nothing to do with that, it's about a *subscriber* getting
the buildd_secret when they should not be able to.

OEM can get it via the +admin screen and indeed that's how they do it.

This bug is a security risk for all private PPAs with subscribers.

[Robert Collins (lifeless)]

On Sat, Feb 26, 2011 at 10:51 AM, Julian Edwards
<email address hidden> wrote:

> Rob, this bug is nothing to do with that, it's about a *subscriber* getting
> the buildd_secret when they should not be able to.

My understanding from you and William was that the best approach in
solving the bug was to remove the thing entirely - essentially making
buildds just another subscriber to the ppa. Do we need to solve the
subscribers getting access issue before e.g. May? If not, we can just
remove the secret then and its all done.

-Rob

[Julian Edwards (julian-edwards)]

Even if we do that, the problem remains the same, it's just using the subscription password instead of a buildd_secret, and a malicious package can steal the credentials.

We need a way of preventing access to the sources.list on the buildd itself. I don't think that's possible as user scripts run as root.

The only other solution I can think of is to prevent people adding private PPAs as dependencies.

[Robert Collins (lifeless)]

What about having one-time credentials for each build? set it when dispatching, hand over the unique url, build happens, credentials are revoked.

[Julian Edwards (julian-edwards)]

That would be quite difficult I imagine - we'd need to have some way of altering the repository .htpasswd file from the buildd-manager. (It's currently written from a cron job running on germanium)

[Robert Collins (lifeless)]

On Thu, Jan 5, 2012 at 11:07 PM, Julian Edwards
<email address hidden> wrote:
> That would be quite difficult I imagine - we'd need to have some way of
> altering the repository .htpasswd file from the buildd-manager.  (It's
> currently written from a cron job running on germanium)

I was thinking something like when a build is requested, create a
one-time-token for it, which germanium lays down, and then when the
buildd-manager is done it removes it. We need to make gemanium's thing
faster (rabbit), and that should be about it.

[Colin Watson (cjwatson)]

Archive.buildd_secret is gone in favour of dynamic authorization and tokens that are only valid for the lifetime of a build.