Upgrade hashbrown to fix security vulnerability

[chookity-pokk]

Summary

indexmap versions 2.7.0 and 2.6.0 pull in hashbrown 0.15.0 which has a high severity vulnerability. This just downgrades to a version that doesn't have that vulnerability.

Details and comments

Just a simple security fix PR.

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[jakelishman]

Thanks for doing this. Dependabot should have done it for us, but it's having a minor problem because of some package constraints we've put on it. I had a half-hearted attempt to fix Dependabot earlier today, but it was the end of my work day, and I was just leaving it for tomorrow.

Can we not update the locked version of hashbrown to 0.15.1, which resolves the problem?

[jakelishman]

I'm not at my computer, but iirc cargo update -p [email protected] is the right command.

[chookity-pokk]

I'm not at my computer, but iirc cargo update -p [email protected] is the right command.

I tried that originally but the newest hashbrown has breaking changes for qiskit that didn't seem simple to solve so I chose to downgrade indexmap.

[jakelishman]

Even just bumping the 0.15.0 versions in the lock files we don't use directly? Bumping the direct requirement on 0.14.5 will cause problems because it's used in interfaces with PyO3 and rustworkx (iirc), but I'm surprised if the non-interface versions used elsewhere are an issue.

[jakelishman]

Also, fwiw, we don't use Borsch serialisation or deserialisation of anything, so I'd be very surprised if we're actually exposed to any related bugs from hashbrown 0.15.0.

[jakelishman]

You have the PR locked so I can't push changes to your branch, but I tried locally, and we can just update the 0.15.0 dep to 0.15.2. If you reset this branch to the state of main, then run cargo update -p [email protected], it should update only the problematic dependency and leave the fixed one intact.

I can open a separate PR if you prefer.

[chookity-pokk]

You have the PR locked so I can't push changes to your branch, but I tried locally, and we can just update the 0.15.0 dep to 0.15.2. If you reset this branch to the state of main, then run cargo update -p [email protected], it should update only the problematic dependency and leave the fixed one intact.

I can open a separate PR if you prefer.

This worked. I think when I tried I must have just done a regular cargo update hashbrown which caused the issues with building the package. Thanks for the help! This should be ready now!

[jakelishman]

No worries, thanks for helping out! Glad to see you guys from q-ctrl here - hopefully there's places we can work together.

[chookity-pokk]

No worries, thanks for helping out! Glad to see you guys from q-ctrl here - hopefully there's places we can work together.

Glad to be here! Hopefully we have plenty of more things to contribute in the future.