Skip to content

feat(core, worker): update worker signature#257

Merged
l1ttps merged 3 commits intomainfrom
feat/worker-signature
Jan 22, 2026
Merged

feat(core, worker): update worker signature#257
l1ttps merged 3 commits intomainfrom
feat/worker-signature

Conversation

@mizhm
Copy link
Copy Markdown
Contributor

@mizhm mizhm commented Jan 22, 2026

No description provided.

Copilot AI review requested due to automatic review settings January 22, 2026 14:10
@gemini-code-assist
Copy link
Copy Markdown
Contributor

Summary of Changes

Hello @mizhm, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request implements a new security layer for worker connections by introducing a mandatory signature validation process. Workers now provide a signature when joining the system, which the core API verifies against a predefined value. This ensures that only authorized workers can connect, significantly improving the overall security posture of the worker infrastructure. The changes involve updates to API contracts, core service logic, and the worker client to support this new authentication mechanism.

Highlights

  • Worker Signature Implementation: Introduced an optional signature field to the WorkerJoinDto across both console API definitions and core API DTOs. This signature is now sent by the worker during its join process and validated by the core API.
  • Core API Signature Validation: The WorkersService in the core API now validates the incoming worker signature against a configured WORKER_SIGNATURE environment variable. An UnauthorizedException is thrown if the signatures do not match, enhancing security for worker connections.
  • Worker Client Update: The worker client (worker/tool/tool.ts) has been updated to send its WORKER_SIGNATURE when attempting to join the core API, ensuring compliance with the new validation mechanism.
  • Dependency Lock File Updates: The package-lock.json and bun.lock files have been updated, primarily adding "peer": true to numerous dependency entries and a "configVersion": 0 to bun.lock, reflecting changes in dependency resolution metadata.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

Updates the worker “join” contract to include a signature and wires it through the worker client and core API join handling.

Changes:

  • Add optional signature to worker join DTOs (core API + generated clients).
  • Pass WORKER_SIGNATURE from the worker when calling /workers/join.
  • Enforce worker signature checking in WorkersService.join.

Reviewed changes

Copilot reviewed 6 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
worker/tool/tool.ts Sends signature on join and reformats strings/headers.
worker/services/core-api/api.ts Updates generated WorkerJoinDto type to include signature?: string.
worker/bun.lock Lockfile metadata update (configVersion).
package-lock.json Large lockfile metadata changes (adds/removes peer flags).
core-api/src/modules/workers/workers.service.ts Enforces signature validation during join.
core-api/src/modules/workers/workers.controller.ts Attempts to plumb signature into gRPC join path.
core-api/src/modules/workers/dto/workers.dto.ts Adds signature?: string to REST join DTO.
console/src/services/apis/gen/queries.ts Updates generated WorkerJoinDto type to include signature?: string.
Comments suppressed due to low confidence (1)

worker/tool/tool.ts:142

  • connectToCore() treats any 401 from /workers/join as an "API key is invalid" case, but with the new signature parameter a 401 may also mean an invalid/missing signature. Also, despite the comment saying "don't retry", the loop continues retrying forever after logging. Consider distinguishing auth failures (API key vs signature) using the server error message/status and aborting (throw/return) on 401 to avoid an infinite retry loop.
        const worker: any = await coreApi.workersControllerJoin({
          apiKey: process.env.API_KEY! || process.env.OASM_CLOUD_APIKEY!,
          signature: process.env.WORKER_SIGNATURE,
        });
        Tool.workerId = worker.id;
        Tool.token = worker.token;
        logger.success(
          `CONNECTED ✅ WorkerId: ${Tool.workerId?.split("-")[0]}`,
        );

        // Wait until Tool.workerId is set (by SSE handler)
        await this.waitUntil(() => !!Tool.workerId, 1000);
        return; // success, exit the method
      } catch (e: any) {
        // If we get a 401 error, don't retry - just throw an API key invalid error
        if (e?.response?.status === 401) {
          logger.error("API key is invalid. Cannot connect to core.");
        }

        attempt++;
        logger.error(
          `Cannot connect to core ${process.env.API} (attempt ${attempt}):`,
        );
        await this.sleep(1000 * attempt); // exponential backoff delay
      }

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

The pull request introduces a new signature field for worker joining, enhancing security by allowing workers to authenticate with a shared secret. The changes span across type definitions, DTOs, the worker controller, and the worker service to implement this new authentication mechanism. There are a couple of high-severity issues related to type consistency and handling of the optional signature field that need to be addressed.

@GrpcMethod('WorkersService', 'Join')
async grpcJoin(requests: {
apiKey: string;
signature: string;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

high

The grpcJoin method's requests parameter type explicitly defines signature: string;, implying it's a required field. However, the WorkerJoinDto (defined in workers.dto.ts and used in the workersService.join method) marks signature as optional (signature?: string;). This type mismatch can lead to unexpected behavior or runtime errors if a gRPC client does not provide the signature field, as the service layer might still expect it based on the controller's type definition.

Suggested change
signature: string;
signature?: string;

Comment on lines +278 to +279
if (signature !== workerSignature) {
throw new UnauthorizedException('Invalid worker signature');
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

high

The WorkerJoinDto defines signature as an optional field (signature?: string). However, the current logic if (signature !== workerSignature) will throw an UnauthorizedException if signature is undefined (which is allowed by the DTO) and workerSignature is a defined string. This means an optional field effectively becomes required, contradicting the DTO's definition. The check should only be performed if a signature is actually provided in the DTO, or workerSignature should also be undefined if no signature is expected.

Suggested change
if (signature !== workerSignature) {
throw new UnauthorizedException('Invalid worker signature');
if (signature && signature !== workerSignature) {

Copy link
Copy Markdown
Member

@l1ttps l1ttps left a comment

Choose a reason for hiding this comment

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

Hey @mizhm, thanks for working on this security enhancement!

The PR looks good overall and adds an important security layer by implementing worker signature validation. The approach of requiring a signature from workers and validating it against a configured WORKER_SIGNATURE environment variable is solid.

However, I noticed a potential security concern that needs to be addressed:

  1. The signature field is marked as optional (signature?: string) in some DTOs but the validation logic treats it as required
  2. The code uses || '' which could allow empty signatures to pass validation if the WORKER_SIGNATURE environment variable is not set
  3. The example.env files don't include the new WORKER_SIGNATURE variable that workers will need

Could you please address these points:

  1. Make the signature field consistently required in the DTO validation when it's expected
  2. Ensure proper handling when WORKER_SIGNATURE is not configured (perhaps fail securely rather than allowing empty signatures)
  3. Update the example.env files to include the WORKER_SIGNATURE variable with appropriate documentation

This security feature is important, so let's make sure it's implemented robustly. Please make these changes and we can merge this.

@l1ttps l1ttps merged commit 6a638ca into main Jan 22, 2026
9 checks passed
@l1ttps l1ttps deleted the feat/worker-signature branch February 1, 2026 02:09
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.

3 participants