chore: fix gosec warnings via ignore annotations in comments #1770
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce?
Fix to gosec warnings so builds can complete.
What is the current behavior?
The gosec checks are halting builds.
What is the new behavior?
The gosec checks are passing.
Additional context
I didn't see any warnings that led to real vulnerabilities / security issues.
That said long term it may be worth adding some defensive bounds checks for a couple of the integer overflow warnings, just to future proof us age the code ages. Given that we allow supabase users to write to the database, not sure we can guarantee a user doesn't provide a bring-your-own-hash singup flow or something like that. Unbound allocations are a prime target for DoS attacks.
For the nonce issues, neither is was real issue. Open is not "fixable, see gosec issue #1211. For Seal I tried:
But it then considers es.Nonce to be stored / hardcoded. The only fix I could get to work was:
It seems the gosec tool requires using
rand.Read
. I changed thecipher.NonceSize()
back to12
(just in case it a numerical constant for a reason) and it started failing again. I think it also checks that cipher.NonceSize() is used as well, just doesn't report that. I ultimately decided to ignore this so there was no changes to crypto functions given the existing code is correct.