Implement HTTP proxy option (#515). #521
Conversation
|
|
|
Is this change waiting on me to resolve the linter error or will someone do that when reviewing/merging it? The "File is not properly formatted (goimports)" message isn't exactly clear what it wants. |
|
I've verified software updates work now through the following process: Build and install app using following commands: After which I could install the official 0.4.1 app update from the restricted network. |
|
@ym if you can tell me what exactly the linter wants I'll get right on it (all I found when googling the error string was other linter runs). FYI SOCKS proxies could be supported in the future (the Go HTTP client does in fact have built-in support), I just limited it to plain HTTP for the time being to keep it simple, but I'll do the rename anyway since its specifically for the HTTP client (unless you think there may be other connections made by the JetKVM in the future which should be able to be proxied). |
|
You can run the linter locally using the following command: golangci-lint run --verboseTo install golangci-lint, please refer to the official installation guide: |
| @@ -111,10 +113,16 @@ func queryHttpTime( | |||
| ctx context.Context, | |||
| url string, | |||
| timeout time.Duration, | |||
| proxyFunc func(*http.Request) (*url.URL, error), | |||
There was a problem hiding this comment.
While this is correct, I suspect we shouldn't really be trusting the clocks on HTTP Proxy server :)
There was a problem hiding this comment.
If the device is on a network where a proxy is required to access the Internet and we want to sync time from a HTTP server, then we don't have much choice here... plus these are plaintext HTTP requests, so if the device is on a hostile network then those servers could be impersonated anyway.
Ensuring integrity of a time source is difficult when you don't have a valid one to start with.
There was a problem hiding this comment.
Now that I'm thinking about it, I wonder if the software should set the device clock to the software build time at boot and reject network times which are older than that, as a protection against a hostile time source being combined with old certificates. Its not perfect, but assuming the software continues to be updated semi-regularly its an improvement.
There was a problem hiding this comment.
Now that I'm thinking about it, I wonder if the software should set the device clock to the software build time at boot and reject network times which are older than that, as a protection against a hostile time source being combined with old certificates.
I like that idea!
Of course that would not be in the scope of this PR :)
This commit adds a "Proxy" field to the network settings screen, which can be used to specify a HTTP proxy for any outgoing requests from the device.
|
@ym is there anything still blocking this change? |
This commit adds a "Proxy" field to the network settings screen, which can be used to specify a HTTP proxy for any outgoing requests from the device.
For testing, I have confirmed direct connections to check for updates work when the device is on an unrestricted network with no proxy set, and proxied connections to check for updates work when the device is on a network without a direct route to the Internet.
I haven't tested the HTTP ti 8000 me syncing or actual download/install of updates as I'm not sure how to exercise them.