No material or immediate-danger concern was identified in this review.
This advisory report describes what the named tools and contextual reviewer found at one exact commit. Unknown or unobserved behavior may still exist.
0 immediate danger0 material5 low
What this review found
No material or immediate-danger item was identified.
Minor cautions
zizmor reported artipacked
Minor caution · medium confidence
The release automation leaves a GitHub access token saved in the build machine's git settings and also writes it to a plain file during the process. Since this only runs when a maintainer merges a release pull request and the token is not shared anywhere, the real-world risk is low, but it is sloppy practice.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The workflow uses actions/checkout@v2 with fetch-depth 0. The checkout action v2 defaults persistCredentials to true, which leaves the GITHUB_TOKEN in the local git config. Additionally, a later step writes the GITHUB_TOKEN to a plaintext file in the workspace. Neither is uploaded as an artifact, and the workflow only triggers on merged pull requests to the release branch, limiting exposure to maintainer-initiated runs. This is a CI hygiene issue, not a runtime extension risk.
Impact: low · Exploitability: unlikely
Developer action: Set persist-credentials: false on the checkout step and avoid writing the token to a filesystem file; pass it via environment variables only.
The release workflow uses a GitHub Action identified by a version label instead of locking it to a specific snapshot. If someone hijacked that label, they could sneak bad code into the release process. This is a best-practice gap, not an active problem.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/create-release@v1 by floating major tag rather than a commit SHA. If the tag were ever moved to a malicious commit, the release workflow could execute untrusted code. This is a CI supply-chain hardening issue; it does not affect the shipped extension runtime.
Impact: low · Exploitability: plausible
Developer action: Pin all third-party actions to a full commit SHA rather than a floating tag.
The checkout step in the release workflow uses a version label instead of a locked snapshot. This is a minor hardening gap in the build process only.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/checkout@v2 by floating major tag. Same supply-chain hardening concern as other unpinned actions. This is a CI-only issue with no impact on the extension's runtime behavior.
Impact: low · Exploitability: plausible
Developer action: Pin actions/checkout to a full commit SHA.
The GitHub Action used to create releases has been archived by its maintainer, meaning it will no longer receive updates or fixes. This is a maintenance concern for the build process only.
Technical evidence
Scanner reason: zizmor matched workflow-security rule archived-uses in this repository.
Contextual assessment: actions/create-release@v1 is from an archived repository and is no longer maintained. While it still functions, relying on unmaintained CI actions is a hygiene risk. This affects only the release pipeline, not the extension runtime.
Impact: low · Exploitability: unlikely
Developer action: Replace actions/create-release@v1 with a maintained alternative such as softprops/action-gh-release, pinned to a commit SHA.
The release script saves a GitHub access key into a plain text file on the build machine. This is not needed and should be avoided even though the risk is low.
Technical assessment
A workflow step writes the GITHUB_TOKEN to a file named gh_token in the runner workspace. Although the file is not uploaded as an artifact and the workflow is maintainer-triggered, writing secrets to the filesystem is unnecessary and increases exposure surface.
Impact: low · Exploitability: unlikely
Developer action: Remove the file-writing step and rely solely on the GH_TOKEN environment variable already set on subsequent steps.