Bump torch minimum to mitigate CVE-2024-31580 & CVE-2024-31583 and enable numpy 2 compatibility

[jamesobutler]

This is a follow-up to the comments made in #8296 (comment).

Description

This bumps the minimum required torch version from 1.13.1 to 2.2.0 in the first commit.

See GHSA-5pcm-hx3q-hm94 and GHSA-pg7h-5qx3-wjr3 for more details regarding the "High" severity scoring.

• https://nvd.nist.gov/vuln/detail/CVE-2024-31580
• https://nvd.nist.gov/vuln/detail/CVE-2024-31583

Additionally, PyTorch added support for numpy 2 starting with PyTorch 2.3.0. The second commit in this PR allows for numpy 1 or numpy 2 to be used with torch>=2.3.0. I have included this commit in this PR as upgrading to torch 2.2 means you might as well update to 2.3 to get the numpy 2 compatibility.

A special case is being handled on Windows as PyTorch Windows binaries had compatibilities issues with numpy 2 that were fixed in torch 2.4.1 (see pytorch/pytorch#131668 (comment)).

Maintainers will need to update the required status checks for the dev branch to:

• Remove min-dep-pytorch (2.0.1)

Types of changes

• Breaking change (fix or new feature that would cause existing functionality to change).
• Integration tests passed locally by running ./runtests.sh -f -u --net --coverage.
• Quick tests passed locally by running ./runtests.sh --quick --unittests --disttests.

[ericspod]

Hi @jamesobutler thanks for the follow-up work on bumping versions. I have tried to get as much working with Numpy2 here without success on older Pytorch versions as expected. We should merge this PR first and then I can make sure Pytorch 2.6 is working there. We've agreed that this version bump should be done so we'll sort the last issues and merge. I don't know quite what to say about the macOS fails, it looks like precision is just slightly off so perhaps a more forgiving threshold in the assert statements is all we need.

[KumoLiu]

/build

[KumoLiu]

Thanks @jamesobutler for the PR, overall looks good to me.
I will update the blossom pipeline accordingly and have removed min-dep-pytorch (2.0.1) in the setting.

Thanks again.

[jamesobutler]

@KumoLiu, did the blossom-ci run for you? I see it listed as failed and I don't see results at https://github.com/Project-MONAI/MONAI/actions/runs/13547599286.

[KumoLiu]

Hi @jamesobutler, could you please add some check for this error?
https://github.com/Project-MONAI/MONAI/actions/runs/13546145548/job/37858127303?pr=8368

And I just removed the pytorch 2.2.2 support in the blossom pipline, if you could resolve the issue above I can help retrigger the blossom.

Thanks again!

[KumoLiu]

/build

[jamesobutler]

For integration I recommend proceeding with the "Rebase and merge" option to integrate the 3 individual commits here to dev to separate out the work between updating to address the CVEs, updating to enable numpy 2, and finally the individual commit to address the macOS testing failures.

[ericspod]

Looks good to me, thanks! We have always used squash-and-merge as the merge strategy to keep the commit logs clean and reduce clutter for the generated release notes. Other PRs which combined changed have been merged in this way without being a major source of confusion. If you're ok with this we can merge that way now.

[jamesobutler]

These commits are organized nicely without a bunch of fix-me-up type commits (and has no merge commits). For git blaming purposes it is nice to have this PR's code diff organized into different commits such as knowing why we switched to assert_allclose. If it gets bundled into one giant commit we lose the specificity around why certain lines of code were needed to be changed. For this reason "Rebase and Merge" would be a good option here.

[ericspod]

@KumoLiu @Nic-Ma If we're ok with rebasing instead of squashing as proposed we can do so now. We would need to change our repository settings to allow this however, so we should have agreement on this beforehand.

[ericspod]

Hi @jamesobutler I've discussed with our core team and we don't think a rebase is a good idea. In Atlassian's documentation they mention that one shouldn't ever rebase on a public branch. I realise Github's behaviour differs from regular git in that it rewrites commits. Rebasing is perhaps fine in this case but we want to avoid any unintended side-effects here and stick to our existing workflow which we know works.

[jamesobutler]

Hi @ericspod, what Atlassian is describing is to not do rebasing of a public branch like dev in a way that rewrites the commit history of dev. Public branches that others depend and branch off should never have its history rewritten and force pushed. The end results of the “Rebase and merge” in this specific case will just integrate these 3 commits and put them on top of the dev branch. This is consistent with how Kitware leads the 3D Slicer project, which is a community that utilizes MONAI. I’ll leave the final choice up to you all for how clean you want to keep your commit history as it will likely be one of you all to run git blame activities in the future which needs a clean git history to be effective.

[ericspod]

Hi @jamesobutler We're going to go ahead with a squash merge, we'll be fine with a number of changes in one commit but we'll take the advice on board, thanks. Also thanks again for this work, it's great to have things updated and a clearer idea for ourselves what our legacy dependency policy should be.

[jamesobutler]

Ok. Yeah with the combined commit of 2e391c8 we have lost the information provided in the commit message body of the Allow forgiving tolerance on some array comparision tests commit in this PR. Hopefully future folks will find their way back to this PR to learn more about the diff changes from the integrated commit.