fix(core): enforce explicit tag length and validation in file keychain - #28523
Conversation
|
📊 PR Size: size/L
|
Summary of ChangesHello, 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 strengthens the security of the file-based credential storage by enforcing a standard 128-bit authentication tag for AES-GCM encryption. By explicitly configuring tag lengths and adding validation checks, the changes prevent potential vulnerabilities related to tag truncation and ensure that the application handles corrupted credential files more gracefully. Highlights
Using Gemini Code AssistThe 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
Customization To customize the 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 Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. 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. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request enhances security in 'FileKeychain' by explicitly setting and validating a 16-byte AES-GCM authentication tag length, and adds corresponding unit tests. The review feedback recommends two valuable improvements: defensively validating the IV length to ensure it is exactly 16 bytes, and refactoring the error handling in 'loadData' to avoid relying on fragile, implementation-specific OpenSSL error message strings.
acccd26 to
5846c45
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request enhances the security of the FileKeychain service by explicitly setting the AES-GCM authentication tag length to 16 bytes and validating the lengths of the IV and authentication tag during decryption. It also refactors error handling during data loading and adds comprehensive unit tests to verify tag length enforcement. The review feedback suggests supporting both 12-byte and 16-byte IVs during decryption to align with standard AES-GCM specifications while maintaining backward compatibility, and logging detailed errors when decryption or parsing fails to facilitate debugging.
e34f5d8 to
ec94ba1
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request updates the FileKeychain service to use a standard 12-byte IV and a secure 16-byte (128-bit) authentication tag for AES-256-GCM encryption, while maintaining backward compatibility for legacy 16-byte IVs. It also introduces strict validation checks for both IV and authentication tag lengths during decryption, refactors error handling in loadData to isolate file reading from decryption/parsing, and adds a comprehensive test suite to verify these changes and prevent truncation vulnerabilities. I have no feedback to provide.
|
Looks like this just needs a few linter issues fixed: Required code changesApply these code modifications to resolve the static analysis failures. 1. Remove console error in file keychainRemove the console logging statement from Note Deleting this log prevents stack traces from cluttering the terminal. The UI Change the try-catch block starting at line 91: try {
const decrypted = this.decrypt(data);
// eslint-disable-next-line @typescript-eslint/no-unsafe-type-assertion
return JSON.parse(decrypted) as Record<string, Record<string, string>>;
} catch (error: unknown) {
throw new Error(
`Corrupted credentials file detected at: ${this.tokenFilePath}\n` +
`Please delete or rename this file to resolve the issue.`,
);
}2. Remove unused variable in reproduction testRemove const ivHex = parts[0];
const authTagHex = parts[1];3. Replace any cast in reproduction testAvoid using the const encryptionKey = (keychain as unknown as { encryptionKey: Buffer }).encryptionKey;otherwise, LGTM. |
c5d7093 to
76d0a51
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request updates the FileKeychain service to use a standard 12-byte IV for AES-256-GCM encryption (down from 16 bytes) and explicitly configures a 16-byte authentication tag length. It also adds validation checks during decryption to reject truncated IVs or authentication tags, and refactors the file loading logic to provide clearer error messages when a corrupted credentials file is detected. A comprehensive test suite has been added to verify these security improvements and ensure backward compatibility with legacy 16-byte IVs. Additionally, helper scripts (test-check.bat and test-check.sh) have been introduced to automate local verification steps. I have no further feedback to provide as the changes are well-implemented and thoroughly tested.
7a45bea to
7f5d8d7
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request updates the FileKeychain service to use a standard 12-byte IV (down from 16 bytes) and explicitly configures a 16-byte authentication tag length for AES-256-GCM encryption. It also adds validation checks for IV and authentication tag lengths during decryption, refactors error handling in loadData to catch and report corrupted credential files more cleanly, and introduces a comprehensive test suite to verify these security and backward-compatibility behaviors. I have no additional feedback to provide as there are no review comments.
DavidAPierce
left a comment
There was a problem hiding this comment.
Thanks for addressing my comment.
LGTM!
Summary
This Pull Request configures explicit authentication tag length and validation
for the file-based credential storage in Gemini CLI. It ensures that the
application strictly enforces standard 128-bit (16-byte) tag lengths across all
supported Node.js runtimes and handles malformed or truncated tags gracefully.
Details
The file-based credential storage in
packages/core/src/services/fileKeychain.tspreviously relied on Node.js's default behavior for AES-GCM tag length
enforcement. To improve robustness and prevent potential issues on legacy
runtimes (where short tags could be accepted without explicit configuration),
this PR applies the following changes:
{ authTagLength: 16 }in bothcrypto.createCipherivand
crypto.createDecipheriv.authTagbuffer isexactly 16 bytes before passing it to
decipher.setAuthTag().loadData()to catch any tag length validation errors and wrap themgracefully in a user-friendly "Corrupted credentials file detected" error.
Related Issues
How to Validate
To validate these changes, run the newly created regression test suite:
should use a secure 128-bit (16-byte) AES-GCM authentication tagshould reject decryption of a credentials file with a truncated tagPre-Merge Checklist