1314160 - Limit or eliminate tasks that "never" expire

Status: RESOLVED WONTFIX

(Taskcluster :: Services, defect, P5)

Description

[Jonas Finnemann Jensen (:jonasfj)]

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.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

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.

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

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.

Comment 3

[Aki Sasaki (not active)]

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.

Comment 4

[Pete Moore [:pmoore][:pete]]

Is this done now?

Comment 5

[Jonas Finnemann Jensen (:jonasfj)]

No, we never scoped expiration.

Comment 6

[Chris Cooper [:coop] (he/him)]

I think this is a feature and not a bug.