A new UI setting was introduced to allow users to run unsigned binarieswithout any input from the user. Defaults to false which means if a binaryis unsigned we will ask the user what to do next.

I moved and modified the logic from CliManager.download to a separatehttp client based on okhttp and retrofit. The refactor will allow usto easily add new steps in the main download method, and also to easilydownload new resources. Long term we could also re-use the okhttp clientto avoid setting twice the same boilerplate (proxy which is missing from CLIManager,hostname verification and other tls settings) between cli downloader and the rest client

From the same source where the cli binary was downloaded.Some of the previous classes like download result were updated to incorporatedetails like where the file was saved or whether a file was found on the remote

`allowUnsignedBinaryWithoutPrompt` was caching the initial value read from thestore, which required a restart of Toolbox for the real value to reflect.

A pop-up dialog is displayed asking the user if he wants to run an unsignedcli version. The pop-up can be skipped if the user configures the `Allow unsigned binary execution without prompt`

…ication

Adds logic to verify the CLI against a detached GPG signature with the help of bouncycastle library

This is the key that validates if the gpg signature was tampered

Initially I thought about embedding it as a const string in the codebut the string is too big, best to save it as resource file.The code changes are mostly related to loading the key from the file.

Signature verification some operations that are cpu bound that are light, likedecoding and decompressing signature data, some medium CPU intensive operationslike the cryptographic verifications and a couple of blocking IO operations:- reading the cli file- reading the signature file- reading the public key fileThese last should run on the IO thread to not block the main thread from drawing the screen.The cpu bound operation should run on the default thread.

previous implementation was selecting only the first key ring from the public key filewhich turns out to be wrong. Instead, we should keep all the key rings and search signaturekey id in all the key rings.

Otherwise, at the next Toolbox restart the signature will no longer be verified,and we run into the risk of running unsigned binaries.

`Files.readAllBytes()` uses direct buffers internally which can be filled up quickly whencalled repeatedly in coroutines, as these buffers are not released quickly by the GC.The scenario can be reproduced by trying to login a couple of times one after the other withsignature verification failing each time.Instead, we can avoid memory issues by streaming the cli and feed only blocks of bytes into the signature calculation.

When there is no signature and the user allowed running of unsigned binaries without prompt

A major feature was added

code-asher left a comment

And also disable the work in progress animations after a fatal error occurred.Most exceptions, especially the ones related to cli signature verification weresuppressed and only displayed in the logs with no visual feedback.

The logic for matching the local CLI version with the deployment previously attempted to runthe CLI with --version without first verifying that the binary existed. This commit improvesthat by first checking if the file exists, avoiding the unnecessary overhead of spawning aprocess for a non-existent binary.

…er-cliRetroactive cli signatures are now published at releases.coder.com/coder-cli/x.y.z/where x.y.z is the major, minor and patch version of the deployment.

…blishedWe now have a lot of signatures published for a lot of older cli version which meanssome of the tests that were not expecting the fallback to activate are now in trouble.The simple fix is to "download" a very old version for which signatures will not be generated.

Instead of deriving the signature name from the cli name it is now codedinto settings store just like the default cli name

It is already supported by java.net.URI

The download and signature verification steps are now slightly altered to first downloadthe cli to a temporary location and only after the signature verification is successfulor the user accepted the risk of running an unsigned binary - then and only then the tempcli is moved to its final location (actually it is just a rename).If the delete fails, this prevents the unsigned binary from being picked up as thecached binary on the next run.

Ask the user if he wants to accept the risk of running a potentially tamperedCLI when signature verification failed (i.e. we downloaded the signatures but eitherit doesn't match or there were some error while computing the signature.

We are going to ask the user only once during the initial login screen if he wants tofallback on releases.coder.com when signatures are not present in the coder deployment.However, we still want to leave him the option to later change his mind the in Settings page.

The user can opt in to fallback on releases.coder.com from the login screenonly once. Later on he can change his mind in the Settings page.

Unless we restart toolbox. This happens because the UI fields are initialized onlyonce when the page is created. If we switch to a different page that can update thesettings (for example the login screen can alter the fallback strategy when signatureare missing) and then come back to the settings page - in that case Toolbox does notrequest the settings again from the settings store.

This happens in the following cases:- if the deployment did not have any signatures and user decided to fallback on  releases.coder.com but the fallback did not have any signature or we failed to download it.- similarly if the user does not want to fallback we still ask him if he wants to run the  unverified cli

jdomeracki-coder left a comment

code-asher left a comment