advanced-security / cocoapods-dependency-submission-action

CocoaPods Lockfile Dependency Submission Action
MIT License
4 stars 3 forks source link

[Bug]: Multiple Podfile.lock files overwrite each other during submission #49

Open ebickle opened 1 month ago

ebickle commented 1 month ago

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 https://github.com/advanced-security/cocoapods-dependency-submission-action/blob/47fe65643f5dcc2116c85274d11c83d0915449dd/cpdsa/__init__.py#L1

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 https://github.com/advanced-security/maven-dependency-submission-action/pull/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:

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

GeekMasher commented 1 month ago

@ebickle thank you for submitting this bug. Let me add it to my backlog next week and resolve this for you