Ignore B614 Use of unsafe PyTorch load.

[tanwarsh]

Summary

Ignored bandit issue B614.

Type of Change (Mandatory)

Specify the type of change being made.

• Security improvement

[MasterSkepticista]

This change introduces unnecessary complexity with minimal user benefit. Torch tensors are routinely loaded using built-ins, and I think there are other areas that may require more attention. I don't think passing this bandit scan is a priority. I recommend closing this PR.

[rahulga1]

This change introduces unnecessary complexity with minimal user benefit. Torch tensors are routinely loaded using built-ins, and I think there are other areas that may require more attention. I don't think passing this bandit scan is a priority. I recommend closing this PR.

@MasterSkepticista I agree that this PR may not be providing user benefit. But lets be clear that Security is an important aspect for any of Intel products. We have taken calls for some bandit issues, where we have closed those due to being false positive, but this is not one of those. So, I won't recommend closing it.
Instead, if you have any suggestion, how we can fix it more appropriately, would appreciate that.

[MasterSkepticista]

I appreciate the focus on security, but in open-source frameworks like these, ease of use, simplicity, and maintainability are equally critical.

These are user convenience APIs and not consumed directly by OpenFL. The intent behind adding {load, save}_native functions was to offer a bridge for users to transfer model weights between OpenFL and their own projects. By using safetensors, we are forcing users to modify their own project code—even when their work may have no connection to OpenFL or Federated Learning. This impacts usability and is not a good user experience in my view.

PyTorch's own recommendation to using torch.{load, save} is that the user must trust the source that they are loading data from. I think this is a fair expectation to have from a user, knowing that they are required to call those functions themselves in their source code.

[tanwarsh]

I appreciate the focus on security, but in open-source frameworks like these, ease of use, simplicity, and maintainability are equally critical.

These are user convenience APIs and not consumed directly by OpenFL. The intent behind adding {load, save}_native functions was to offer a bridge for users to transfer model weights between OpenFL and their own projects. By using safetensors, we are forcing users to modify their own project code—even when their work may have no connection to OpenFL or Federated Learning. This impacts usability and is not a good user experience in my view.

PyTorch's own recommendation to using torch.{load, save} is that the user must trust the source that they are loading data from. I think this is a fair expectation to have from a user, knowing that they are required to call those functions themselves in their source code.

In this case, Can we ignore this bandit issue @rahulga1 ?

[rahulga1]

I appreciate the focus on security, but in open-source frameworks like these, ease of use, simplicity, and maintainability are equally critical.
These are user convenience APIs and not consumed directly by OpenFL. The intent behind adding {load, save}_native functions was to offer a bridge for users to transfer model weights between OpenFL and their own projects. By using safetensors, we are forcing users to modify their own project code—even when their work may have no connection to OpenFL or Federated Learning. This impacts usability and is not a good user experience in my view.
PyTorch's own recommendation to using torch.{load, save} is that the user must trust the source that they are loading data from. I think this is a fair expectation to have from a user, knowing that they are required to call those functions themselves in their source code.

In this case, Can we ignore this bandit issue @rahulga1 ?

Please note this down and ignore this. If PSE comes back, we go ahead with this explanation.
FYI @psfoley

[kta-intel]

Would setting weights_only=True work? Starting with torch 2.6, that flag will be set by default without the pickle_module argument https://pytorch.org/docs/stable/notes/serialization.html#weights-only.

Since we only load the state dictionaries, it will still align with expectations from OpenFL's perspective without sacrificing user experience.

Btw, load_native() actually isn't currently exposed to the user (or used at all, for that matter)