Limit or eliminate tasks that "never" expire

NEW
Unassigned

Status

Taskcluster
Queue
P5
normal
2 years ago
2 months ago

People

(Reporter: jonasfj, Unassigned)

Tracking

Details

(Reporter)

Description

2 years ago
Stages:
1) Put task.expires > 1 year behind a scope, while granting the scope to everybody
   By giving it to "assume:*" using the "*" role.
2) Ensure nobody has the scope
3) Remove support for task.expires > 1 year

This way we can gradually migrate away from it.
Step (1) will break things that uses authorizedScopes, temporary credentials,
and task.scopes without referencing any roles.

But that's hopefully an uncommon use-case.
From the ML discussion, there are some legitimate uses for expirations greater than one year -- in particular, validating the chain of trust for builds made more than a year ago (per Aki).  So I don't think we'd ever get rid of this scope.  In fact, potentially every level-3 build would need a multi-year expiration, in a build-promotion world.

Also, step 1 would break the world, for the reasons you described.

Rather than breaking everyone's tasks, I would suggest analyzing new tasks with long expirations, and chasing down the people who can either change the expiration times or explain why they need long times.  In the latter case, set up the long-expiration scope for whatever is creating those tasks.
Summary: Limit task.expires to 1 year → Limit or eliminate tasks that "never" expire
BTW, two years might be OK for chain-of-trust?  That's doubling the storage costs, which may be significant if it applies to all level-3 builds, but it's better than "forever".

This bug should also encompass manually expiring many of the existing "forever" tasks -- likely a large portion of them are completely unnecessary.
Flags: needinfo?(aki)

Comment 3

2 years ago
I think I'm ok with a year.  I was mainly pointing out that if we wanted to reduce the overlap where we had two sets of the same binaries, we could reduce the release artifact expiration to much less than a year, but we would need chain of trust to be verifiable in the beetmoved area.  We might want chain of trust to be verifiable in the beetmoved area anyway, but a year gives us enough time to audit ESRs if wanted.
Flags: needinfo?(aki)
Is this done now?
Flags: needinfo?(jopsen)
(Reporter)

Comment 5

3 months ago
No, we never scoped expiration.
Flags: needinfo?(jopsen)
(Reporter)

Updated

2 months ago
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.