Expired firmware urls

[coop]

My NervesHubLink.Client put off applying an update for about 2hrs - when it could finally apply the update I received a 403 error:

23:58:07.301 [error] Error: 403 "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Error><Code>AccessDenied</Code><Message>Request has expired</Message><X-Amz-Expires>600</X-Amz-Expires><Expires>2020-02-20T22:31:45Z</Expires><ServerTime>2020-02-20T23:58:07Z</ServerTime><RequestId>501B108E5DA8A2CA</RequestId><HostId>HvSXlrvHhH69s/SlISC3KHr+x+MI3CpDRdZttQVlYCmLInQ2DT+fS1qxeIV8Eulu7SF5TeiruXM=</HostId></Error>"

@jjcarstens did some digging and found that there is a hardcoded 600s ttl on objects put into the fw bucket on s3.

It's normal that our devices won't be able to apply an update for a couple of hours so I'm wondering if the ttl should be configurable or should the client not error on 403 and somehow request a new signed url?

Thanks.

[fhunleth]

I think this can be updated. Several of us are at conferences the next two weeks, and I suspect that it will be hard to get fixed and reviewed until after those are over.

I personally like your idea of having clients request a new signed url if they get a 403. It seems like if we go the direction of lengthening the ttl, we'll be regularly bumping it upwards.

[mobileoverlord]

I agree that this should be handled by requesting a new presigned URL instead of trying to bump ttl's

[jjcarstens]

To make it easier for the client, we'll need to add a channel message to support the client requesting a check for update

[joshk]

I'm going to close this issue as the TTL for a firmware download is currently set to 24 hours.

I also agree that a client should request a new firmware URL, which would allow us to reduce the TTL to 5 or 10mins, but we should open up a different issue for that, possibly in https://github.com/nerves-hub/nerves_hub_link as https://github.com/nerves-hub/nerves_hub_link_http has been archived.