impl: verify cli signature #148
Conversation
A new UI setting was introduced to allow users to run unsigned binaries without any input from the user. Defaults to false which means if a binary is unsigned we will ask the user what to do next.
I moved and modified the logic from CliManager.download to a separate http client based on okhttp and retrofit. The refactor will allow us to easily add new steps in the main download method, and also to easily download new resources. Long term we could also re-use the okhttp client to 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 incorporate details like where the file was saved or whether a file was found on the remote
`allowUnsignedBinaryWithoutPrompt` was caching the initial value read from the store, 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 unsigned cli version. The pop-up can be skipped if the user configures the `Allow unsigned binary execution without prompt`
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 code but 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, like decoding and decompressing signature data, some medium CPU intensive operations like the cryptographic verifications and a couple of blocking IO operations: - reading the cli file - reading the signature file - reading the public key file These 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 file which turns out to be wrong. Instead, we should keep all the key rings and search signature key 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 when called 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 with signature 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
src/main/kotlin/com/coder/toolbox/cli/downloader/CoderDownloadService.kt
Outdated
Show resolved
Hide resolved
| // remove the cli, otherwise next time the user tries to login the cached cli is picked up, | ||
| // and we don't verify cached cli signatures | ||
| Files.delete(cliResult.dst) |
There was a problem hiding this comment.
I think cliResult.dst is the final location, is that right? Should we download to a temporary location and then rename after verification instead? Advantages:
- If the delete fails, this prevents the unsigned binary from being picked up as the cached binary on the next run.
- If there was previously a signed (but outdated) binary, it will be left alone so the user can fall back to it if they want, if they are having trouble with downloading or verifying the new binary.
| else -> { | ||
| // remove the cli, otherwise next time the user tries to login the cached cli is picked up, | ||
| // and we don't verify cached cli signatures | ||
| runCatching { Files.delete(cliResult.dst) } |
| if (signatureResult.isNotDownloaded()) { | ||
| context.logger.info("Trying to download signature file from releases.coder.com") | ||
| signatureResult = withContext(Dispatchers.IO) { | ||
| downloader.downloadReleasesSignature(showTextProgress) |
There was a problem hiding this comment.
For air-gapped folks, I wonder if even attempting to reach out externally by default could be seen as a security risk. I think possibly this should be gated behind an option?
And maybe it should be defaulted to false, or maybe it is sufficient to communicate ahead of time about the option if we default it to true.
Or it could be a prompt, maybe. "Got 404 trying to download signature from $coder_url. Try downloading signature from releases.coder.com?" Something like that.
Although, will we always bundle the signature files with coderd? If so, this block will never execute right? (Except for an error downloading the signature from coderd, although maybe we should abort when there are errors.) Edit: I suppose it would be ran if coderd is an older version without the signatures.
There was a problem hiding this comment.
will they also provide a public pgp key? will they continue to use detached gpg signatures? The code is now targeted for gpg signature verification.
There was a problem hiding this comment.
Honestly not sure, maybe @jdomeracki-coder has an idea. If I understand correctly, the releases.coder.com fallback is only necessary for verifying older versions, and I am not sure if air-gapped teams will want to bother hosting their own service just to provide signatures for older binaries.
If that is true, then maybe all we need is an option that toggles whether to reach out externally for signatures, so it can be skipped in the air-gapped case.
Mostly though I am just worried that security teams will see the Coder extension reaching out to our servers and get spooked. But idk if this is a realistic worry, I am not a security expert 😅
| }.let { result -> | ||
| when { | ||
| result.isSkipped() -> return false | ||
| result.isNotFoundOrFailed() -> throw IllegalStateException("Could not find or download Coder CLI") |
There was a problem hiding this comment.
Could we throw with the original error message? That one seems useful since it contains the response code and the URL.
| } | ||
| } | ||
|
|
||
| private fun getCoderPublicKeyRings(): List<PGPPublicKeyRing> { |
There was a problem hiding this comment.
Some folks have forked the CLI, should we provide a way they can add their own public keys to sign their own binaries or would we recommend they set the allowUnsignedBinaryWithoutPrompt setting for that case? (Also assumes there is a way to remove or replace the signature files in coderd, and it also has implications for the fallback to releases.coder.com).
| } else { | ||
| val acceptsUnsignedBinary = context.ui.showYesNoPopup( | ||
| context.i18n.ptrl("Security Warning"), | ||
| context.i18n.pnotr("Can't verify the integrity of the Coder CLI pulled from ${cliResult.source}"), |
There was a problem hiding this comment.
Thinking out loud: could we somehow make use of verifyDownloadLink here?
My thinking is, it uses an allow list, and it could be nice to allow the same list as we do for downloading the editors. This could even be used in place of allowUnsignedBinaryWithoutPrompt. verifyDownloadLink also resolves redirects so it shows the final URL (although maybe it should show both the original and final URLs).
Pressing "accept" could also add the URL to the allowlist for subsequent attempts (maybe it should be a third option like "Accept permanently" or something).
| conn.sslSocketFactory = coderSocketFactory(settings.tls) | ||
| conn.hostnameVerifier = CoderHostnameVerifier(settings.tls.altHostname) | ||
|
|
||
| if (signatureResult.isNotDownloaded()) { |
There was a problem hiding this comment.
I could see reaching out to releases.coder.com if the signature was a 404, but should we be doing this if we got an error downloading the signature? Like a 502 or whatever? My thinking is that should be a hard failure (it would mean a problem with the deployment). Or a prompt asking whether to continue.
src/main/kotlin/com/coder/toolbox/cli/downloader/CoderDownloadService.kt
Outdated
Show resolved
Hide resolved
And also disable the work in progress animations after a fatal error occurred. Most exceptions, especially the ones related to cli signature verification were suppressed and only displayed in the logs with no visual feedback.
The logic for matching the local CLI version with the deployment previously attempted to run the CLI with --version without first verifying that the binary existed. This commit improves that by first checking if the file exists, avoiding the unnecessary overhead of spawning a process for a non-existent binary.
…er-cli Retroactive 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.
…blished We now have a lot of signatures published for a lot of older cli version which means some 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 coded into settings store just like the default cli name
It is already supported by java.net.URI
This PR introduces support for verifying the CLI binary using a detached PGP signature. Starting with version 2.24, Coder signs all CLI binaries. For clients using older versions or running TBX in air-gapped environments, unsigned CLIs can still be executed—either without a prompt or with an optional confirmation prompt.
In terms of code changes - the PR includes a big refactor around CLI downloading with most of the code refactored and extracted in various components that provide clean steps and result state in the main download method. Then the pgp verification logic was added on top, with some particularities: