[Bug]: Multiple Podfile.lock files overwrite each other during submission #49
Description
What happened?
This is based on a review of the code plus work on other dependency submission actions, so it's not confirmed but a likely issue.
The GitHub dependency submission API uses the commit (hash), the 'tool name', and the 'job correlator' as a unique identity as part of a dependency submission. If a second submission occurs with the same values, it will overwrite the earlier one.
If a lockfile is not specified as an argument, __main__.py will check for every lock file beneath the current directory. For each file, depgraph.submitDependencies is called.
submitDependencies calls Dependencies.exportBOM which uses a constant tool value for the job.correlator, job.id, and detector.name. The tool name is a constant defined at
If I'm right, this means that subsequent podfiles will overwrite earlier ones. In addition, if a user manually specifies a value for cocoapods-lock it bypasses walking the directory tree finding podfiles and directly submits the specified one. This is also an issue if a caller uses the action more than once - e.g. manually specifying two podfiles in via a workflow matrix, which would cause a race condition.
The Maven dependency submission action had a similar issue, which had a workaround added at advanced-security/maven-dependency-submission-action#88. There was some interesting feedback on potentially adding the path of a file as part of the correlator as a long term work around.
My suggestion for a fix:
- Compute a hash of the relative path to each podfile.lock (e.g.
SHA256('./path1/path2/path3/path3/Podfile.lock')). Append the hash to the job id of the run (the other submission actions use the job id as the correlator) or use the hash as-is as the correlator. Correlators are truncated to a max length of 255, so hashing helps avoid issues with long paths in repos. - Use the workflow run id as the default value for
job.id. This matches the other actions. It's unclear whether there's any issue with submitting a constant, but the API design seems to want a unique value per submission here.
Hopefully that helps! Alternately, go pester someone else at GitHub to add direct support for parsing Podfile.lock files in Dependabot. Even if there's no vulnerability database for Cocoapods yet, 50% of iOS developers still use Cocoapods and React Native (heavily used) still seems dependent on that ecosystem. 😎
Version
v1
Relevant log output
No response