Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checksum type comparison is case-sensitive #13470

Closed
calligraf0 opened this issue Jul 2, 2024 · 4 comments
Closed

Checksum type comparison is case-sensitive #13470

calligraf0 opened this issue Jul 2, 2024 · 4 comments

Comments

@calligraf0
Copy link
Contributor

calligraf0 commented Jul 2, 2024

Not sure this is a widespred problem, or a problem at all (might be intended behavior).
I couldn't see any other open issue about it.

I worked on a possible fix, I'm opening a PR.
Spoiler alert: I am not too familiar with ruby :) so if I use any unsafe or wrong/deprecated functions: any feedback is welcome!

Debug output

vagrant up dc --provision
Bringing machine 'dc' up with 'vmware_desktop' provider...
==> dc: Box 'gusztavvargadr/windows-server-core' could not be found. Attempting to find and install...
    dc: Box Provider: vmware_desktop, vmware_fusion, vmware_workstation
    dc: Box Version: >= 0
5==> dc: Loading metadata for box 'gusztavvargadr/windows-server-core'
    dc: URL: https://vagrantcloud.com/api/v2/vagrant/gusztavvargadr/windows-server-core
==> dc: Adding box 'gusztavvargadr/windows-server-core' (v2102.0.2404) for provider: vmware_desktop (amd64)
    dc: Downloading: https://api.hashicorp.cloud/vagrant/2022-08-01/gusztavvargadr/boxes/windows-server-core/versions/2102.0.2404/providers/vmware_desktop/amd64/vagrant.box
    dc: Calculating and comparing box checksum...
The specified checksum type is not supported by Vagrant: SHA256.
Vagrant supports the following checksum types:

md5, sha1, sha256, sha384, sha512

Expected behavior

Comparison should work, regardless of case, since choices are limited to supported checksums anyway.

Actual behavior

While comparing a box checksum vagrant maps the checksum type against this map:

CHECKSUM_MAP = {
    :md5 => Digest::MD5,
    :sha1 => Digest::SHA1,
    :sha256 => Digest::SHA256,
    :sha384 => Digest::SHA384,
    :sha512 => Digest::SHA512
  }.freeze

this makes any comparison with a box which specifies the checksum type in UPPERCASE fail to map.

Reproduction information

Vagrant version

2.4.1

Host operating system

Archlinux

Guest operating system

Windows, but shouldn't matter.

Steps to reproduce

  1. Try to download the following box: gusztavvargadr/windows-server
  2. Fails checksum regardless of type

Vagrantfile

Vagrant.configure('2') do |config|
  # Vagrant allowed IP ranges: 192.168.56.0/21
  config.vm.provider "vmware_desktop"

  config.vm.define 'dc' do |dc|
    dc.vm.box = 'gusztavvargadr/windows-server'

    dc.vm.provider 'vmware_desktop' do |dcv|
      dcv.vmx["memsize"] = "4096"
      dcv.vmx["numvcpus"] = "4"
    end
  end
calligraf0 added a commit to calligraf0/vagrant that referenced this issue Jul 2, 2024
@calligraf0 calligraf0 changed the title Checksum type comparison fails is case-sensitive Checksum type comparison is case-sensitive Jul 2, 2024
@gusztavvargadr
Copy link

gusztavvargadr commented Jul 2, 2024

@calligraf0 great that you did the research and proposed a fix. There was a similar issue earliear at #13466 but it was closed.

We're tracking this as well regarding the templates and the box publishing at gusztavvargadr/packer#444. I have moved my boxes recently to the HCP Vagrant Registry, I suspect this might have something to do with the checksum types being returned differently.

@gusztavvargadr
Copy link

@calligraf0 FYI, I have removed the checksum from all the providers of my boxes for their latest versions to unblock their downloads.

The issue can be tested with their previous versions, in case of Windows Server it would be 2102.0.2403.

@calligraf0
Copy link
Contributor Author

Thanks for the heads up!

I'm sure I would have gone crazy figuring out why it wouldn't replicate anymore haha!

chrisroberts added a commit that referenced this issue Jul 10, 2024
@chrisroberts
Copy link
Member

This was fixed on the server side and #13471 that @calligraf0 provided was merged as well to add a bit better resiliency on the client side for things like this. My apologies for the issues this has caused.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 10, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants