update hashing functions from md5 to sha256

[kranurag7]

What this PR does

updates all instances of md5 to sha256.

Which issue(s) this PR closes

N/A (there were no open issues about this)

Checklist

• Unit, integration, and e2e (if applicable) tests updated
• Documentation added (or pr:no public docs PR label added if not required)
• Added the relevant release notes label (see labels prefixed w/ release:). These labels dictate how your PR will
  show up in the autogenerated release notes.

[CLAassistant]

All committers have signed the CLA.

[mamccorm]

+1

[Konstantinov-Innokentii]

Hi! First of all, thanks for the contribution!

That said, could you clarify why this change is necessary? MD5 isn’t used to hash anything sensitive, like passwords—it’s only used to generate alert group distinction, which are solely for grouping purposes.

Additionally, this change seems likely to break grouping for open alert groups. Since the new hash function would generate different group distinction, new alerts that should belong to an existing group might end up in a separate one.

[maxgio92]

I think FIPS compliant environments with strict enforcement in OpenSSL would benefit from this change, as hashlib.md5() would fail otherwise

[Konstantinov-Innokentii]

I think FIPS compliant environments with strict enforcement in OpenSSL would benefit from this change, as hashlib.md5() would fail otherwise

Thanks for the clarification. Is it possible to implement it under the feature flag or something, so users who do not need it will still use md5 & they will not receive unexpected pages during the update?

[kranurag7]

Additionally, this change seems likely to break grouping for open alert groups. Since the new hash function would generate different group distinction, new alerts that should belong to an existing group might end up in a separate one

Hey @Konstantinov-Innokentii I would like to understand more of why it's a breaking change, changing to sha256 should be safe here right. I am thinking more on the line that md5 gives you random keys and sha256 will give you same randomness but a little longer. Is there something more detailed that I need to understand here in case I missed something here.

[Konstantinov-Innokentii]

Hey @kranurag7!
So, the initial state of the system is:

1. OnCall is running with md5 hash used for grouping
2. There is an open AlertGroup; let's assume it's grouped by field payload.system
   ––––
   So, the PR is merged, we released a new oncall version and oncall instance version is updated
   ––––
3. New alert with same value of payload.system is received.
4. The new version of the code calculated group distinction using sha256 instead of md5.
5. These values are different despite the payload.system being the same. So, instead of grouping the alert into the open group, OnCall will create a new group. Which may cause some unexpected paging.

That's why I'm asking why this change is needed & if it's for some security compliance – is it possible to use sha256 only under feature flag.

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!