Add bandit to CI for security linting

[strickvl]

Added bandit to the CI to detect medium and high severity warnings about code we write.

(Made some fixes to handle the errors it found -- some were ignored (like hashing algorithms where security was not the intended purpose) and other small fixes were just made.)

For the timeout changes, I read that it's best to choose something that is 1 larger than a multiple of 3, and then beyond that I just chose values that I thought made sense for that particular piece of code.

Pre-requisites

Please ensure you have done the following:

• I have read the CONTRIBUTING.md document.
• If my change requires a change to docs, I have updated the documentation accordingly.
• If I have added an integration, I have updated the integrations table and the corresponding website section.
• I have added tests to cover my changes.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Other (add details above)

[avishniakov]

Generally, looks good, one question here: you made all those exclusions here and there to suppress known security vulnerabilities? Why I'm asking: some of them are not hard to fix, like switching from md5 to else and so on.

[strickvl]

@avishniakov good question. The problem with changing the hashing algorithm relates to backwards compatibility. i.e. anyone upgrading to a newer version would have the hashes stored in the database using the old algo but this update would mean we essentially wipe / invalidate their cache (in a way that perhaps does unexpected things). To do it in a graceful way would be fairly involved, I felt, where we'd have to maybe store the hashing algorithm in the database along with the hash itself.

Since none of the places where we're currently using old hashing algorithms involve security, I felt like it was an ok tradeoff. It will prevent us from adding any new places where we're using broken hashing algorithms and we can potentially consider switching out the places where it's ignored going forward as part of a bigger ticket.

[strickvl]

You're right though that the fix is basically replacing md5 with sha256, but that would break things in unpredictable ways, I thought.

[schustmi]

What was the reason for the various different timeout adjustments (5/7/31/#nosec) for the different requests?

[strickvl]

What was the reason for the various different timeout adjustments (5/7/31/#nosec) for the different requests?

@schustmi see the PR description. I didn't want to make it generically long, but that said I can also see that it might be confusing. Not sure what the right way to handle this is. Raw request.get() without a timeout passed in was flagged as a medium risk.