You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our default RequestsFetcher sets this default value:
self.socket_timeout: int = 4 # seconds
sigstore-python patches this:
# NOTE: We poke into the underlying fetcher here to set a more reasonable timeout.
# The default timeout is 4 seconds, which can cause spurious timeout errors on
# CI systems like GitHub Actions (where traffic may be delayed/deprioritized due
# to network load).
fetcher = RequestsFetcher()
fetcher.socket_timeout = 30
return fetcher
I agree with sigstore-python on this:
Trying to defend against slow-retrieval attacks is in my opinion impossible in practice, especially for a generic library that could be used in a large number of contexts (it may be possible for a specific application). Even with 4 sec timeout a server could return 1 byte every 3 seconds without triggering this limit: that's a download speed of 30kB per day.
This theoretical defense is creating real world bugs as documented above
Requests by default does not set a timeout at all: We should set a default timeout (because indefinite hangs are also not cool) but we should set it without trying to solve slow-retrieval attacks at all: 30 secs sounds good to me.
The text was updated successfully, but these errors were encountered:
Our default RequestsFetcher sets this default value:
sigstore-python patches this:
I agree with sigstore-python on this:
Requests by default does not set a timeout at all: We should set a default timeout (because indefinite hangs are also not cool) but we should set it without trying to solve slow-retrieval attacks at all: 30 secs sounds good to me.
The text was updated successfully, but these errors were encountered: