grass icon indicating copy to clipboard operation
grass copied to clipboard

CSC 472 initial PRs

Open jadenabrams100 opened this issue 1 year ago • 3 comments

Included here are some initial changes we have made as part of CSC 472: Cybersecurity Projects to increase the security posture of the GRASS GIS project.

jadenabrams100 avatar Feb 19 '24 00:02 jadenabrams100

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

I understand that this seems to be part of a university class, and it might be one of your first contributions other projects, and I welcome that!

It might be easier to review if the changes were grouped per type of change rather than a big one with multiple concerns mixed together. And if you could think about a descriptive title for them that would be better suited for the title of the final commit that will stay in the source code history, something better than the title of a university class (I assume). The goal is to be able to know what a PR does just by reading it, and it doesn't do other things mixed in or hidden in it. It's also easier to revert if there's a problem, and also easier years later when trying to find what change caused something, or why it was done.

For example, there seems to be some changes for the CodeQL workflows, but it ends up only adding a way to manually trigger it. What is the link with the rest? (I know it allows to run for a specific branch at when we want it, useful when working on its implementation). For Bandit, have you thought about including it as a job, or a step in our existing Python code quality workflows? How would running this on a schedule change our possibilities to act upon it? Would we need to read the logs anyways, just like when they are run in a PR or on main?

echoix avatar Feb 19 '24 02:02 echoix

Do you know if bandit is reimplemented inside of Ruff? Or is only a small subset of rules are included. It might be interesting to use it.

Also, if bandit supports configuration inside of the pyproject.toml file, it would be more appropriate to place the exclusions there. It would allow to change the CI action in tube future easily, and be able to use the tool itself locally without having to port the configuration again.

echoix avatar Feb 19 '24 02:02 echoix