we currently use Signotaur to sign a long list of files using --file-list and specify a number of timestamp servers with --timestamp-server and --fallback-timestamp-server.
After signing a number of files the primary timestamp server will reject further requests for a while so signotaur will use the first fallback server until that one fails and so on.
This seems to waste a lot of time however because signotaur will keep trying to use the same servers in the same order for every single file in the list, having to wait for a timeout every single time.
Previously we would sign each file individually and randomise the order of the timestamp servers.
Is there a way to do the same when using a file list?
There isn’t currently a way to do this, but it’s a good suggestion.
I have not seen a timestamp server reject requests before - we need need to figure out if they are using standard 429 response codes and whether they include the retry-after header. I’m guessing each timestamp server handles it differently.
Looking into this, the main issue is that it tries the primary on each file in the list, with a 30s timeout I can see why that would cause issues.
We’re working on an update that will fix this, plus handle any rate limiting that we are able to detect (assuming the ts actually follows the norms - the RFC doesn’t actually spell out any rate limiting).