Skip to content

Add binary signature verification #558

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

code-asher
Copy link
Member

@code-asher code-asher commented Jul 23, 2025

I extracted the download function (since I needed to reuse it to download signatures) to a separate commit so it is easier to review the signature additions separately, if that is of interest.

This downloads the detached signature from Coder if available or releases.coder.com if not, then verifies the binary using that detached signature and the bundled public key. The check is performed only when the binary is first download.

  • Add option to disable
  • Skip headers when requesting releases.coder.com
  • Tests (for signing, no tests for the UI changes, ideally we get something set up to do that at some point, although we could mock the VS Code APIs in the meantime...)

@code-asher code-asher force-pushed the asher/binary-verification branch 2 times, most recently from 753e955 to 3e18934 Compare July 23, 2025 20:45
The main thing here is to pass in an Axios client instead of the SDK
client since this does not need to make API calls and we will need to
pass a separate client without headers when downloading external
signatures.

Otherwise the structure remains the same.  Some variables are renamed
due to being in a new context and some strings messages are simplified.
A tiny refactor since I will need to get a third config option.
@code-asher code-asher force-pushed the asher/binary-verification branch 2 times, most recently from 33b14b9 to 18c3c88 Compare July 23, 2025 21:59
@code-asher code-asher force-pushed the asher/binary-verification branch from 18c3c88 to 860b1aa Compare July 23, 2025 22:11
@code-asher code-asher requested a review from aslilac July 23, 2025 22:15
They are not needed, and the packaging step will error that it looks
like you are trying to package secrets due to the test key fixtures.
Copy link
Member

@aslilac aslilac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm gonna need you to sign a waiver indicating that you know I'm not a cryptography expert and will not be held responsible for any glaring security issues before you merge this 😝 but it looks good!

case VerificationErrorCode.Invalid:
return "Signature does not match";
default:
return "Failed to read signature";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return "Failed to read signature";
return "Failed to verify signature";

since this is the default, it might not necessarily be about reading I guess?

Copy link
Member Author

@code-asher code-asher Jul 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah true, there are only two error codes and the other is read so as it currently is this is accurate, but if in the future a code was added and someone did not update the switch statement, we could possibly return the wrong message. I think I can make use of never instead in some way to force the switch to be exhaustive, will fix

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Waaaaiiit looks like TypeScript is smart about this now?? No need to do anything special. When did that happen lol

So I can just replace default with VerificationErrorCode.Read and all is well.

src/pgp.ts Outdated
Comment on lines 84 to 91
return new VerificationError(VerificationErrorCode.Invalid, error);
}
} catch (e) {
const error = `Failed to read signature or binary: ${errToStr(e)}.`;
logger?.warn(error);
return new VerificationError(VerificationErrorCode.Read, error);
}
return true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel weird about returning errors in js. if these were thrown instead we could do something like...

try {
  await verifySignature(...);
  // more happy path here
} catch (error) {
  if (error instanceof VerificationError) {
    // unhappy path here
  }
}

which is maybe a bit noisier than what you're currently doing, but is also a bit more "when in rome", y'know?

Copy link
Member Author

@code-asher code-asher Jul 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are probably right, initially I did it that way but the added nesting felt like too much, although I did break things up after that so it would not be quite so bad now. Edit: also the type checking is unfortunate, we have to add code to check this is a verification error but it can never be anything but that, actually I think this was the real reason.

Do you think I can get away with it if I call it VerificationResult instead lol

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ehhhh nvm on second thought I will throw

@code-asher
Copy link
Member Author

cc @jdomeracki-coder in case you want to take a look, should be similar to the JetBrains plugin but I went with the original flow instead of the checkbox during login since we can have prompts with multiple buttons here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy