-
Notifications
You must be signed in to change notification settings - Fork 9.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: add codeql analysis #32745
test: add codeql analysis #32745
Conversation
I like the idea of automated testing but CodeQL was proposed before and, looking at the results linked above, I think the response still applies. By all means implement this as a separate optional workflow. If there were
I'd be even happier. For instance, by specifying a single commit or range of commits, it should be possible to generate CodeQL That would have found things like the second "Inefficient RE" |
codeql will not fail a workflow unless the PR introduces NEW issues... you can always merge the PR anyway if you don't agree with the reason why it failed it
I've never tried it, but there is a CLI option. The python run in GitHub workflows is pretty quick (~3 minutes), so never gave it much thought. https://docs.github.com/en/code-security/codeql-cli/getting-started-with-the-codeql-cli/setting-up-the-codeql-cli As for the comments on your linked PR, you can always close the security issues if you don't agree them. The security issues opened by codeql will be private, so anyone who you don't give explicit permission to view them won't be able to. Anyway, I only opened this because I've added youtube-dl as a submodule (due to no updated pypi package), so the codeql I run in my repo will include issues found in the submodule... and It has found 24 possible issues in this project. |
You can feel free to ignore/close off the issues that were flagged. If this was enabled for PRs, I'd only want to flag issues found in the new/changed code. With the linter (flake8) workflow, the rules are secretly changed from time to time, causing a swathe of new diagnostics from previously checked code. No doubt this would be true with CodeQL too, but those diagnostics should only be shown to PR devs if the PR itself is affected. Regarding PyPi, you can |
That's precisely how it works. The schedule, runs against your master branch to get new baselines (you can always adjust the frequency of this, right now it's on weekly). For PRs it only flags NEW potential issues. Here's an example PR that would have introduced new security issues. The comments on the PR notify the submitter, and they can fix the issues before it's merged. It doesn't notify of existing issues (this would actually be a security risk because it would make the possible security vulnerabilities public). LizardByte/Themerr-plex#130
Dependabot can't keep those up to date, so I opted to use a submodule instead. Using a branch without specifying a commit is not an option. Builds would vary between one to the next and it would be impossible to track when something breaks. |
You can specify a commit instead of a branch, or |
I'm aware. The issue is that dependabot won't track it, unfortunately... And I don't have the capacity to manually update dependencies all the time. So I opted for the submodule route, which dependabot can track. |
Please follow the guide below
x
into all the boxes [ ] relevant to your pull request (like that [x])Before submitting a pull request make sure you have:
In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:
What is the purpose of your pull request?
Description of your pull request and other information
Explanation of your pull request in arbitrary form goes here. Please make sure the description explains the purpose and effect of your pull request and is worded well enough to be understood. Provide as much context and examples as possible.
This PR adds CodeQL (security) analysis.
It will check security of the python code on the following events.
CodeQL will check for known vulnerabilities in the code. It will also check for exposed tokens.
This will enable the security tab of your repo, and create security events there similar to issues, however they are private to the repo owner (and probably specific people you specify).
It will also fail PRs if they introduce new security issues. You can setup branch protection rules to block these PRs from being merged, by forcing the job to pass (along with your standard CI) if you wanted to.
I highly suggest implementing CodeQL as it will alert you of issues, and help you have more secure code.
You can see the analysis results of this PR here once finished running ->
https://github.com/ytdl-org/youtube-dl/security/code-scanning?query=is%3Aopen+pr%3A32745