[CentOS-devel] Vagrant ignores checksums, instead of validating them

Hi there,

Emmanuel Kasper of the Debian Cloud Team contacted me about two days 
ago: they discovered that Vagrant simply ignores any --checksum 
parameter when adding the box.  You can even provide "1234" instead of a 
valid SHA256 sum, and Vagrant will just add the downloaded box, without 
any warning or error whatsoever:

vagrant box add --checksum-type sha256 --checksum 1234 --provider
libvirt --box-version 1710.01 centos/7

==> box: Loading metadata for box 'centos/7'
     box: URL: https://atlas.hashicorp.com/centos/7
==> box: Adding box 'centos/7' (v1710.01) for provider: libvirt
     box: Downloading:
https://vagrantcloud.com/centos/boxes/7/versions/1710.01/providers/libvirt.box
==> box: Successfully added box 'centos/7' (v1710.01) for 'libvirt'!

echo $?
0

Our signatures are basically useless for most users: Vagrant will only 
check the signature if one is included in the metadata (which is not the 
one in the box we host, but generated by Vagrant Cloud, formerly known 
as Atlas - there's simply no way to get Hashicorp's servers to include 
the checksum, not even for the boxes they host themselves).  The 
--checksum argument is honored if you add a raw box, but I doubt our 
users would be willing to do that, even if they knew about it:

$ vagrant box add --checksum-type sha256 --checksum 1234 --name c7tmp 
https://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7-x86_64-Vagrant-1710_01.Libvirt.box
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'c7tmp' (v0) for provider:
     box: Downloading: 
https://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7-x86_64-Vagrant-1710_01.Libvirt.box
     box: Calculating and comparing box checksum...
The checksum of the downloaded box did not match the expected
value. Please verify that you have the proper URL setup and that
you're downloading the proper file.

Expected: 1234
Received: 9d1ddb812de88578326538d69fdd5f59ba68adf04862144300c42d0293f61d2f
$ echo $?
1


Another possibility would be to also host the metadata ourselves, along 
with the raw boxes, on cloud.centos.org.  Endymion can already generate 
the needed metadata, and I already verified that Vagrant works properly 
with it, even detecting newer versions of the boxes for updates.  The 
problem of convincing our users to use a cloud.c.o URL instead of Atlas 
still remains.

I guess I'll have to replace the section in our future release 
announcements about verifying the images downloaded from Atlas with some 
sort of warning.  Any other ideas of what we could do?  Vagrant's 
behavior is described in its documentation, so I assume it's by design.

How about adding the missing Vagrant functionality as distro patches, if 
upstream doesn't want to?

Regards,
Laurențiu


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878759
https://github.com/lpancescu/endymion