Windows: tarball and zip handlers return OS-native path separators instead of normalized repository paths

[Tanishq-mellu]

Summary

While running Scorecard tests on Windows 11 with Go 1.26.4, I observed failures in both the GitHub tarball and Azure DevOps zip handlers due to path separator differences.

The tests expect repository-style paths using forward slashes (/), but the handlers return Windows-native paths using backslashes (\).

Environment

• OS: Windows 11
• Go: go1.26.4
• Repository: ossf/scorecard
• Branch: main

Reproduction

GitHub tarball handler:

go test ./clients/githubrepo -run TestExtractTarball -v

Azure DevOps zip handler:

go test ./clients/azuredevopsrepo -run TestExtractZip -v

Expected Behavior

Repository-style paths should be returned consistently across platforms:

dir1/file1
dir1/dir2/file2

Actual Behavior

On Windows, the returned paths use native separators:

dir1\file1
dir1\dir2\file2

Example test output:

Expected:
["file0" "dir1/file1" "dir1/dir2/file2"]

Got:
["file0" "dir1\file1" "dir1\dir2\file2"]

Investigation

I traced the issue to the file extraction handlers where extracted file paths are stored after trimming the temporary directory prefix.

For example, in clients/githubrepo/tarball.go:

handler.files = append(
    handler.files,
    strings.TrimPrefix(
        filenamepath,
        filepath.Clean(handler.tempDir)+string(os.PathSeparator),
    ),
)

[Tanishq-mellu]

I investigated further and tested a local change using filepath.ToSlash() before storing extracted paths. This resolved the path separator mismatch in my Windows environment. Happy to prepare a PR if path normalization is the intended behavior.

[Tanishq-mellu]

I validated the issue locally on Windows 11 (Go 1.26.4).
The failing behavior reproduces in:

• clients/githubrepo (TestExtractTarball)
• clients/azuredevopsrepo (TestExtractZip)
• clients/gitlabrepo (TestExtractTarball)

All three fail because repository paths are returned with Windows path separators (\) while the tests expect normalized repository-style paths (/).

Example:

Expected:
dir1/file1

Actual:
dir1\file1

The issue appears consistent across multiple repository handlers rather than being isolated to a single implementation.
I'm investigating whether normalizing extracted paths before storing them in the handler file lists is the appropriate fix.

[Tanishq-mellu]

I investigated this issue further on Windows 11 using Go 1.26.4.
I was able to reproduce the path separator failures in the GitHub, GitLab, and Azure DevOps handlers. The extracted file paths were being stored with Windows path separators (\) while the tests expected normalized repository-style paths (/).
I tested a local fix that normalizes stored paths using filepath.ToSlash() before appending them to the handler file lists. After applying the change, the original path separator assertion failures no longer reproduced.
There are still separate Windows cleanup failures related to temporary files being in use during cleanup, but those appear independent from the path normalization issue.

If path normalization is the intended behavior, I'd be happy to prepare a PR for this fix.