1093452 - taskcluster-base: Should not require auth:credentials scopes

Status: RESOLVED INVALID

(Taskcluster :: General, defect)

Description

[James Lal [:lightsofapollo]]

While working on the dockerhost-worker I found that I needed this scope to use TC base https://github.com/taskcluster/taskcluster-base/blob/bccdb70ecadefba58cfafd15245e5a23650792c6/api.js#L280 (auth:credentials) which _appears_ to allow me to fetch the accessToken for _any_ clientId I know about.

This seems pretty sketchy when we have auth:inspect which simply allows returning the scopes.

Comment 1

[James Lal [:lightsofapollo]]

Any ideas (or is this just a bug/configuration issue) ? I want to use TC base but in my case allowing auth:credentials is pretty bad.

Comment 2

[Jonas Finnemann Jensen (:jonasfj)]

You can validate an HMAC signature without the shared secret.

You can still use taskcluster-base API utilities... Just make a custom implementation of `clientLoader` and can  be provided as argument in the setup... auth.taskcluster.net does this.

Instead of loading clients from auth.tc.net as the default clientLoader does, you just return clients from a JSON object. In your case the object is provided via. task.payload and is encrypted using openpgp.js.
Remember to embed taskId, deadline and creation time in the signature... See the bug on encrypted environment variables it explains in detail how to avoid Trudy decrypting it by submitting another or a similar task...

Note, people should obviously not include their own clientId/accessToken in the task.payload, they should generate a random clientId and a random accessToken. This random set of credentials will be unique to the specific task they upload...


Note, the context of this is that James is working on a worker that offers an API after it has started.

Comment 3

[Pete Moore [:pmoore][:pete] [PTO until 13 April 2026]]

Resetting Version and Target Milestone that accidentally got changed...