Relax TUF's timeouts/"slow downloads" check #431
Description
Just filing this issue from discussion with @jku for tracking purposes.
We've seen some spurious CI failures due to SlowRetrievalErrors coming from TUF -- the default timeout for stalled network activity seems to be 4s, which is probably a little too short for GitHub Actions (where traffic prioritization/shaping might mean longer delays).
More generally, I think TUF's default here doesn't play a substantial role in either Sigstore or sigstore-python's security/threat model: it's hard to imagine (possibly due to a lack of imagination on my part) a situation with verification would "fail open" due to a timeout of 4s versus one of, say, 30 seconds. There should still be some timeout that produces a hard error rather than a soft one (e.g. to prevent an attacker from masking repo updates by slowing them down), but 30s seems more reasonable for our use case.
(This needs to be more than just a unit test carveout, because we expect people to use sigstore-python in their CI pipelines.)