chore: Cherry-pick changes from upstream - #137
Conversation
Signed-off-by: Anurag Rajawat <anurag@stepsecurity.io>
|
📦 Target Release Version: |
🔍 Cherry-Pick Verification Report📦 Upstream Changes: 📋 File-by-File Analysis:
|
PR ReviewAction TypeNode-based action - runs on ✅ Passed Checks
❌ Failed Checks
|
PR Review\n\n### Action Type\nNode-based action - runs on
|
|
test body simple |
|
PR Review body with no hashes at line starts - test 2 |
|
test with no hashes and no newlines |
|
Test line 1 |
Test header at startregular line after |
|
placeholder |
PR ReviewAction TypeNode-based action - runs on ✅ Passed Checks
❌ Failed Checks
|
1 similar comment
PR ReviewAction TypeNode-based action - runs on ✅ Passed Checks
❌ Failed Checks
|
|
|
||
| fs.chmodSync(sopspath, '777') | ||
| if (!isExecutable(sopspath)) { | ||
| fs.chmodSync(sopspath, '777') |
There was a problem hiding this comment.
chmod 777 is overly permissive. Setting the mode to 777 makes the binary world-writable, which on shared or self-hosted runners allows any local process to overwrite the cached sops binary — a potential supply-chain / TOCTOU attack vector. The mode 755 (owner-writable, all-execute) is the conventional and safer choice for a downloaded binary.
| fs.chmodSync(sopspath, '777') | |
| fs.chmodSync(sopspath, '755') |
|
|
||
| test('downloadSops() - does not throw when chmod on an already-executable cache hit would fail with EPERM', async () => { | ||
| mockFind.mockReturnValue('pathToCachedDir') | ||
| mockPlatform.mockReturnValue('linux') |
There was a problem hiding this comment.
Misleading test name — EPERM path is never exercised. This test sets mockAccessSync to succeed (returns undefined), so isExecutable() returns true and chmodSync is never called at all. The EPERM error configured on mockChmodSync is dead code in this test.
The test is actually a duplicate of the skips chmod on a cache hit that is already executable test above it. To genuinely test the EPERM scenario described in the name and the source-code comment, the test would need mockAccessSync to throw (so the binary is not considered executable) and mockChmodSync to throw EPERM — then verify the error propagates (or is swallowed, depending on the desired behaviour). Consider either renaming this test to reflect what it actually asserts, or rewriting it to cover the real EPERM path.
🔍 Cherry-Pick Verification Report📦 Upstream Changes: 📋 File-by-File Analysis:
|
mdgreenwald/mozilla-sops-action@v2.1.0...v2.1.1