scorecard
scorecard copied to clipboard
Feature - Pin dependencies - add support for gclient DEPS file
Is your feature request related to a problem? Please describe.
Yes, dart and flutter use gclient from chromium to manage third party dependencies. We would like to add Pin dependencies support for this type of files.
Describe the solution you'd like Unfortunately parsing DEPS file without python may be challenging. We would like to run python in a subprocess to flatten up the third party dependencies from DEPS to identify dependencies that are not pinned.
Describe alternatives you've considered
An alternative would be to try to parse the file directly from go but it would be very difficult to cover all possible corner cases.
Additional context N/A
Thanks for reporting this @godofredoc. I wonder if a Python parser like https://pkg.go.dev/github.com/go-python/[email protected] can be used here? If the code complexity of these DEPS files tends to be fairly simple we could get away with not being able to handle all corner cases.
I have added the needs discussion label to this issue so that we can bring this up during the Scorecard sync next week. If possible please do drop by so that we can get your inputs on this. You can find the details to the meet and our Slack channel here: https://github.com/ossf/scorecard#connect-with-the-scorecards-community
one way we get around this problem for other package managers is that we search commands that fail unless the dependencies are pinned. For example for pip, we check for use of pip ... --require-hashes.; and we warn otherwise.
Is there something similar for gclient?
gclient does not support checking for pinned dependencies but I can try to contact the owners and see if there is interest on implementing that functionality.
Alternatively we can autogenerate a flattened DEPs file and only check for the pinned dependencies from scorecards using a plain text file with one dependency per line.
gclient does not support checking for pinned dependencies but I can try to contact the owners and see if there is interest on implementing that functionality.
that'd be really helpful. Let us know if there's something we can help with.
Alternatively we can autogenerate a flattened DEPs file and only check for the pinned dependencies from scorecards using a plain text file with one dependency per line.
what do you mean by autogenerate?
gclient does not support checking for pinned dependencies but I can try to contact the owners and see if there is interest on implementing that functionality.
that'd be really helpful. Let us know if there's something we can help with.
Alternatively we can autogenerate a flattened DEPs file and only check for the pinned dependencies from scorecards using a plain text file with one dependency per line.
what do you mean by autogenerate?
gclient supports hooks that run as part of the source code checkout process, here is an example. We can add an additional hook that writes a file with the list of dependencies. This will be committed to the repository as DEPS_list, pinned dependencies check can read files called DEPS_list and validate them using regular expressions.
pros:
- Scorecards won't need a additional dependency on gclient depot_tools
cons:
- Anyone that wants to use DEPS pinned dependencies validation will need to flatten their dependencies and commit the autogenerated file to the repositories under test
Alternatively we can autogenerate a flattened DEPs file and only check for the pinned dependencies from scorecards using a plain text file with one dependency per line.
I presume this is not a norm among the clients of gclient? If so, it might be a bit hacky to do this. How many repos would benefit from something like this? If its a reasonable number, we could consider this as a first step while working out a more general solution.
@azeemshaikh38 you are correct generating the flattened file is a work around and it won't be generic.
I've been thinking on other potential solutions and I believe I found one to make the DEPS implementation generic.
The overall workflow would look like:
- A python script to flatten the deps can be checked into oosf/scorecards/scripts. The script is pretty simple <100 lines
- The score cards pinned dependencies can look for all the DEPS files in the repository under test. If there is a DEPS file, scorecards can check if python is available in the host running the checks, if it is not available then we add an alert that a DEPS file was found and python is required to validate it.
- The python script can run as a subprocess from scorecards to get the list dependencies and run the regular expressions on each line to check they are all pinned.
Some caveats given that the DEPS file is being parsed we won't be able to correlate failures with specific lines.
Please let me know what do you think about this potential solution.
Update from the WG discussion:
- Running a Python script in Go might pose security risks.
- gclient is used by Chromium and also by Flutter + Dart.
- 3 potential options to solve this: (i) Pre-flatten the DEPS file (ii) Run a Python script as subprocess in Golang (iii) Use a Golang parser of Python
As our next step here, consider starting with (i) as it is simple & secure and can help Chromium, Flutter + Dart teams. Meanwhile @godofredoc to send a Python script for (ii) which Scorecard team will review and consider moving to (ii) long-term to make this a generic solution.
Is there any update on this thread?
I finished implementing the python script part. Here is the PR:
https://github.com/flutter/engine/pull/32135
I'll send the validation of pinned dependencies to scorecard the next week.
I finished implementing the python script part. Here is the PR:
I'll send the validation of pinned dependencies to scorecard the next week.
Is it going to be in python? We can't run Python.
The parser step in the actions workflow will generate a file called "deps_flatten.txt" and from scorecards side I was planning to just scan for deps_flatten.txt files and then run all the pinning analysis and report extending one of the existing pin checks.
Would that work or do you mean that it is not recommended to run python as part of the scorecards github actions workflow in the target repository?
The parser step in the actions workflow will generate a file called "deps_flatten.txt" and from scorecards side I was planning to just scan for deps_flatten.txt files and then run all the pinning analysis and report extending one of the existing pin checks.
Sorry, this is still not clear. Is actions workflow scorecard actions?
Would that work or do you mean that it is not recommended to run python as part of the scorecards github actions workflow in the target repository?
Do you want to run Python as part of scorecard actions?
Probably a design document/diagram can help visualize and clarify the understanding.
The parser step in the actions workflow will generate a file called "deps_flatten.txt" and from scorecards side I was planning to just scan for deps_flatten.txt files and then run all the pinning analysis and report extending one of the existing pin checks.
Sorry, this is still not clear. Is
actions workflowscorecard actions?
Using https://github.com/flutter/engine/pull/32135 as an example .github/workflows/scorecards-analysis.yml is the workflow that will be running the python script to generate the deps_flatten.txt in the local checkout before the scorecard actions run.
Would that work or do you mean that it is not recommended to run python as part of the scorecards github actions workflow in the target repository?
Do you want to run Python as part of scorecard actions?
No, python will run as part of the workflow that runs the scorecard actions in the repository under test.
Probably a design document/diagram can help visualize and clarify the understanding.
Sure, please let me know if after the explanations above a design doc will still be required and I'll be happy to write it.
Sounds good. Thanks. Is there any work that would be required from the scorecard project with respect to this?
I believe only code reviews will be needed, I'm planning to send the PR.
This issue is stale because it has been open for 60 days with no activity.