Make targets expiry very long

[jku]

There's currently open signing events for both root and targets. We could just sign them ... but how about this as a plan:

• set targets expiry period to very long like snapshot (in staging it's 10 years)
• keep root expiry at 3 months (this is more frequent than prod just to get some experience)

This should get us the same advantages (mainly regular test for root key existence) with signing events that are smaller (so easier to review)

I will make a change in one of the open signing events to implement this: feel free to voice a differing opinion though.

CC @kommendorkapten @joshuagl @mnm678 @haydentherapper

[jku]

To be clear, I intend to propose this for production too once that time comes

[kommendorkapten]

I totally agree on changing the targets expiration to a long time.

[joshuagl]

There's currently open signing events for both root and targets. We could just sign them ... but how about this as a plan:

* set targets expiry period to very long like snapshot (in staging it's 10 years)

Isn't this repo staging?

* keep root expiry at 3 months (this is more frequent than prod just to get some experience)

This should get us the same advantages (mainly regular test for root key existence) with signing events that are smaller (so easier to review)

And, importantly, no real loss in security, right?

I agree with the decision to extend the expiry period of targets metadata to a long time.

I think it's worth capturing the rationale somewhere in the project's documentation, as this may appear counterintuitive on first examination.

[jku]

Isn't this repo staging?

Yeah my phrasing was not ideal: I just meant that I used the same expiry period value as snapshot since the logic for both is kind of the same: We want to sign these files but think there is no need for them to expire in our case so chose the value 10 years.

And, importantly, no real loss in security, right?

Yes, this is my understanding: There is no scenario where offline targets resigning (without key rotations) makes the repository more secure.

Short documentation makes sense: it should capture at least:

• chosen number of signers
• expiry and signing period lengths for different roles

[jku]

This is now done. #129 exist for documenting rationale