fix: incorrect conversion between integer types

[tenthirtyam]

Summary

Fixes incorrect conversion of an unsigned 32-bit integer from to a lower bit size type int32 without an upper bound check.

Testing

packer-plugin-vsphere on  fix/incorrect-conversion via 🐹 v1.23.0 
➜ go fmt ./...

packer-plugin-vsphere on  fix/incorrect-conversion via 🐹 v1.23.0 
➜ make test   
?       github.com/hashicorp/packer-plugin-vsphere      [no test files]
?       github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/common/testing [no test files]
ok      github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/clone        2.267s
?       github.com/hashicorp/packer-plugin-vsphere/examples/driver      [no test files]
?       github.com/hashicorp/packer-plugin-vsphere/version      [no test files]
ok      github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/common       4.408s
ok      github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/driver       12.610s
ok      github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/iso  4.657s
ok      github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/supervisor   12.468s
ok      github.com/hashicorp/packer-plugin-vsphere/post-processor/vsphere       6.774s
ok      github.com/hashicorp/packer-plugin-vsphere/post-processor/vsphere-template4.488s

Reference

• https://github.com/hashicorp/packer-plugin-vsphere/security/code-scanning/3
• https://github.com/hashicorp/packer-plugin-vsphere/security/code-scanning/4
• https://github.com/hashicorp/packer-plugin-vsphere/security/code-scanning/5

[lbajolet-hashicorp]

Thanks for the PR @tenthirtyam,

At first glance it would seem that the clamping is unnecessary as ParseInt already errors if the value can't fit on the provided bitSize, that said I understand this is meant to silence the errors reported by CodeQL, but I wonder if there's some other way we can document that those checks don't need to exist, and that they shouldn't be reported.

That said, those checks don't fundamentally harm the code so I'm not completely against merging this, but I think we would benefit from investigating how we can silence this check as it is being too cautious I think.

[lbajolet-hashicorp]

LGTM! Thanks for the reroll @tenthirtyam.

Only thing I can think of left is maybe using %s for interpolating errors in the error string, as you did a PR not too long ago to harmonise that, it may be good to continue using %s for those use cases.

That said it's very nitpicky so feel free to disregard if you think it's find as-is

Pre-approving to not block later