[ANE-2955] Fix vendored archive uploads with absolute paths by nficca · Pull Request #1713 · fossas/fossa-cli

nficca · 2026-05-19T16:58:49Z

Overview

fossa analyze with archive uploads crashes when any vendored-dependencies[].path is absolute. It fails with withBinaryFile: permission denied while trying to write the tarball at the filesystem root. The meta-fossa Yocto layer always emits absolute paths, so every archive-upload run from it hits this.

The temp filename builder kept a leading / for absolute inputs and that escaped the intended output directory. Fix strips the root component so the tarball stays where it should.

Acceptance criteria

Archive-upload fossa analyze succeeds when a vendored dep path is absolute, including for the meta-fossa Yocto integration.

Testing plan

Stage a vendored source dir at any absolute path:

mkdir -p /tmp/vendor/foo
echo "license: MIT" > /tmp/vendor/foo/LICENSE

Create a project dir with a fossa-deps.json pointing at it:

mkdir /tmp/project && cd /tmp/project
cat > fossa-deps.json <<'JSON'
{
  "vendored-dependencies": [
    { "name": "foo", "version": "0.0.1", "path": "/tmp/vendor/foo" }
  ]
}
JSON

Run analyze, forcing archive upload so this code path is exercised regardless of org default:

cabal run fossa -- analyze -p abs-path-repro -r v1 \
  --force-vendored-dependency-scan-method ArchiveUpload

Against master, the run dies with withBinaryFile: permission denied on a path starting with /_tmp_vendor_foo.... With this branch, the run succeeds and the vendored dep shows up in the project on app.fossa.com.

Risks

Behaviour change is scoped to absolute-path inputs; relative paths produce the same filename as before.

Metrics

None.

References

ANE-2955: Yocto integration yielding no results.

Checklist

I added tests for this PR's change (or explained in the PR description why tests don't make sense).
If this PR introduced a user-visible change, I added documentation into docs/.
If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an ## Unreleased section at the top.
If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.

No docs/schema/subcommand changes needed. Changelog entry under a new ## 3.17.7 section since this is intended to ship as the next release.

safeSeparators kept the root "/" as a leading element of its output, and the System.FilePath.Posix.(</>) at the call site treats an absolute RHS as the result. That made compressFile try to write the tarball at the filesystem root and fail with EACCES on non-root users. This is the default code path for archive-upload runs from the meta-fossa Yocto layer, which always emits absolute paths in vendored-dependencies. Filter "/" components out before joining so the result stays relative.

coderabbitai · 2026-05-19T18:16:34Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Organization UI (inherited)

Review profile: ASSERTIVE

Plan: Pro

Run ID: 77d5ed14-d199-42af-8453-6475af3ba388

📥 Commits

Reviewing files that changed from the base of the PR and between 435a371 and 27d36ab.

📒 Files selected for processing (3)

Changelog.md
src/App/Fossa/VendoredDependency.hs
test/App/Fossa/VendoredDependencySpec.hs

Walkthrough

This PR fixes a crash in vendored dependency archive uploads when using absolute file paths. The safeSeparators function is now exported from the module and modified to filter out the root "/" component before normalizing path separators. The function previously included all directory components as-is, which caused permission errors during tarball creation with absolute paths. Tests verify the new behavior handles relative paths, single filenames, and absolute paths correctly. A changelog entry documents the fix for release 3.17.7.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the main change: fixing vendored archive uploads when absolute paths are used, directly addressing the bug described in the PR.
Description check	✅ Passed	The PR description is comprehensive and well-structured, following the template with all major sections filled out including overview, acceptance criteria, testing plan, risks, references, and checklist.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

csasarak

Can you address my comments re: windows? Aside from that nothing is blocking.

csasarak · 2026-05-20T19:23:58Z

+      safeSeparators "foo/bar" `shouldBe` "foo_bar"
+    it "leaves bare filenames untouched" $
+      safeSeparators "foo" `shouldBe` "foo"
+    it "drops the root component for absolute paths" $
+      safeSeparators "/foo/bar/baz" `shouldBe` "foo_bar_baz"


I strongly recommend making these paths in an abstract way. Something like:

do currDir <- getCurrentDirectory -- Should make an absolute path safeSeparators `shouldSatisfy` (not . any (== pathSeparator))

The reason is that our path finding libraries will use the OS native path format. I think if you constructed the paths more abstractly, this test would fail on our Windows build and probably should.

csasarak · 2026-05-20T19:24:14Z

+-- intended output directory.
 safeSeparators :: FilePath -> FilePath
-safeSeparators = intercalate "_" . splitDirectories
+safeSeparators = intercalate "_" . filter (/= "/") . splitDirectories


Would it be sufficient to just remove leading /? Not requiring a change, just trying to make sure I understand the problem.

You may also want to consider if this code will work on Windows. https://hackage-content.haskell.org/package/filepath-1.5.5.0/docs/System-FilePath.html#g:1

Use platform-agnostic `System.FilePath.dropDrive` and `splitDirectories` so the function handles Windows drive letters and UNC roots, not just Posix `/`. Test now seeds from `getCurrentDir` to exercise OS-native paths on each CI platform.

csasarak

LGTM

hellow554 · 2026-05-21T07:10:00Z

Sorry to hijack this, I was the person who reported this.

Currently the script is putting all the data into a directory under /tmp.

This is - under linux at least - backed up by my RAM.
My files are much bigger than my RAM can handle, therefore this doesn't succeed.

So the question is:

Is there a way to modify the path via the cli or fossa.yaml?
If not, can we put it into the current working dir instead of temp?

nficca · 2026-05-21T14:34:01Z

Hi @hellow554. You should be able to modify the path of temp directory we use like so:

TMPDIR=/some/path fossa analyze ...

We use Path.IO.withSystemTempDir to create temp directories, which on POSIX reads TMPDIR before falling back to /tmp.

If this doesn't work for you, I'll ask that you file a new support ticket as this is a separate issue than the one fixed in this PR.

nficca added 4 commits May 19, 2026 12:58

Scope absolute-path compressFile test to Posix

c378485

Drop Posix-only compressFile test, keep safeSeparators unit tests

fc71e92

Use generic paths in safeSeparators tests

27d36ab

nficca marked this pull request as ready for review May 19, 2026 18:14

nficca requested a review from a team as a code owner May 19, 2026 18:14

nficca requested a review from GauravB159 May 19, 2026 18:14

csasarak requested changes May 20, 2026

View reviewed changes

Make safeSeparators portable across Windows

5e59069

Use platform-agnostic `System.FilePath.dropDrive` and `splitDirectories` so the function handles Windows drive letters and UNC roots, not just Posix `/`. Test now seeds from `getCurrentDir` to exercise OS-native paths on each CI platform.

nficca requested a review from csasarak May 20, 2026 20:04

csasarak approved these changes May 20, 2026

View reviewed changes

nficca merged commit ea2335e into master May 20, 2026
19 checks passed

nficca deleted the ane-2955-vendored-abs-path branch May 20, 2026 20:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[ANE-2955] Fix vendored archive uploads with absolute paths#1713

[ANE-2955] Fix vendored archive uploads with absolute paths#1713
nficca merged 5 commits into
masterfrom
ane-2955-vendored-abs-path

nficca commented May 19, 2026 •

edited

Loading

Uh oh!

coderabbitai Bot commented May 19, 2026

Uh oh!

csasarak left a comment

Uh oh!

csasarak May 20, 2026 •

edited

Loading

Uh oh!

csasarak May 20, 2026

Uh oh!

csasarak left a comment

Uh oh!

Uh oh!

hellow554 commented May 21, 2026

Uh oh!

nficca commented May 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

nficca commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

Acceptance criteria

Testing plan

Risks

Metrics

References

Checklist

Uh oh!

coderabbitai Bot commented May 19, 2026

Walkthrough

Uh oh!

csasarak left a comment

Choose a reason for hiding this comment

Uh oh!

csasarak May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

csasarak May 20, 2026

Choose a reason for hiding this comment

Uh oh!

csasarak left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

hellow554 commented May 21, 2026

Uh oh!

nficca commented May 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

nficca commented May 19, 2026 •

edited

Loading

csasarak May 20, 2026 •

edited

Loading