Hardcoded timeout in updater.DownloadTarget

[eikenb]

go-tuf/metadata/updater/updater.go

Line 248 in 990cdb8

data, err := update.cfg.Fetcher.DownloadFile(fullURL, targetFile.Length, time.Second*15)

We're hitting the timeout above when downloading files using the updater and want to raise it. Maybe this should be passed in as a parameter or added to the UpdaterConfig? Our current workaround is a re-implementation of the DownloadTarget() function that lets us set that value.

[rdimitrov]

hey, @eikenb 👋

Thanks for the raising this 👍 So far we haven't had anyone else raise that 15 seconds are not enough to download a target, but I do see how hardcoding it can become an issue (big targets, slow network, etc) 👍

I've briefly checked the specification and there's no explicit mentioning of it, so it's up to the implementations to set this accordingly. That said I agree it's fair to make this configurable 👍

We'll add it to the project planning and we'll try to include in the next release. Of course we'll be more than happy to welcome a PR in case you already have something on your side 🙌 That would make things move up much faster.

[sureshkrishnan-v]

Hi, I’d like to work on this issue as a first-time contributor—could you confirm if it’s available and share any guidelines?

[rdimitrov]

@sureshkrishnan-v - Thanks for volunteering! Let's see in case @eikenb already have something prepared there and if not you'll be safe to proceed 👍

As for the guidelines the idea is to make this timeout configurable and not hardcoded to 15s. If it's not set during initialisation, we can safely default to 15 second, but otherwise we should use the value set in the configuration. Does that make sense?

[sureshkrishnan-v]

Ok, the timeout hardcoded to 15s needs to be configurable else it defaults to 15s am I right? and need to know how can I get time from updaterconfig struct will it be set at initialisation time ?

[rdimitrov]

Yes, it should be available through config.UpdaterConfig 👍

But again, I would wait to see in case @eikenb has anything already prepared so we don't duplicate the same work twice 👍

[sureshkrishnan-v]

ok i will wait

[eikenb]

@rdimitrov @sureshkrishnan-v ... Sorry for the delayed response. I don't have time to write anything for this currently. So no blocker on my end to letting @sureshkrishnan-v work on it.

Thanks for the consideration and great to hear it will be addressed.

[rdimitrov]

Thanks for the reply, @eikenb 🙏

@sureshkrishnan-v - I'll assign it to you 👍