Drop the iso_checksum_type & iso_checksum_url fields

[azr]

In favor of simply using iso_checksum that will know what to do.

[rgl]

basing this on the hash length is not correct because there are several hash functions that can have the same output length, e.g., SHA-2 256 vs SHA-3 256.

[azr]

Hey @rgl, thanks for your concern; I nerd sniped myself a little to check some of what you said. So basically what I found out is that sha-256 is currently at sha-4 and previous versions of sha ( sha-1, 2, 3 ) have been 'deprecated' and by default go implements "sha-04 - 256" from FIPS "180-04" : https://golang.org/src/crypto/sha256/sha256.go?s=3821:3841#L6 FIPS-04.

So that's one thing; but this doesn't prevent hashing algorithms from having the same length; but it is still possible to tell the go-getter which algorithm you want from the hashing string, for example:

By using something like ./foo.txt?checksum=md5:b7d96c89d09d9e204f5fedc4d5d55b21 and a file containing checksums can also tell what checksum is being used, ( or not and then we will fallback to guessing based on length of hash ).

[rgl]

Hey @rgl, thanks for your concern; I nerd sniped myself a little to check some of what you said. So basically what I found out is that sha-256 is currently at sha-4 and previous versions of sha ( sha-1, 2, 3 ) have been 'deprecated' and by default go implements "sha-04 - 256" from FIPS "180-04" : https://golang.org/src/crypto/sha256/sha256.go?s=3821:3841#L6 FIPS-04.

Don't known what is this "sha-04 - 256" you are talking about. The hashing algorithm is called SHA-2 and the other one is SHA-3; both have variants with the same output length (e.g. 256-bit).

So that's one thing; but this doesn't prevent hashing algorithms from having the same length; but it is still possible to tell the go-getter which algorithm you want from the hashing string, for example:

By using something like ./foo.txt?checksum=md5:b7d96c89d09d9e204f5fedc4d5d55b21 and a file containing checksums can also tell what checksum is being used, ( or not and then we will fallback to guessing based on length of hash ).

Ah, so I can use, e.g., iso_checksum = 'sha3-256:xxxx', so its all good :-)

[azr]

Okay I had to update the tests but this looks good to review ; basically foo is not a valid base64 encoded string ( because it contains an 'o' ) and therefore is invalid; so I used 0B0F137F17AC10944716020B018F8126 (or 0b0F137F17AC10944716020B018F8126 ) everywhere, this comes from md5("packer")

[sylviamoss]

Looks really good to me :D

[sylviamoss]

Nice!!

[sylviamoss]

Nice!!!

[sylviamoss]

at this point this is always true, so I guess you can remove it.

[azr]

There is also a possibility that the checksum is set from the iso url.

[sylviamoss]

Reading their changelong it appeared that they had some changes to the ec2 API which we use but it doesn't say anything about backward incompatibilities and it wasn't too many changes. For me is ok updating the version, unless you have another concern.

[SwampDragons]

Just noticed -- this needs a fixer.

[SwampDragons]

We need a fixer for this! If there's a checksum_type, we need to delete it from the config and prepend it to the iso_checksum field.

[azr]

Okay I think I can merge this one 🙂

[azr]

Ah bummer I wanted to change the commit message

[SwampDragons]

This is probably the most major backwards incompatibility we've introduced in my time working on Packer. It will affect basically every template. And while packer fix feels like an easy lift for a power user, not all of our users even know that feature exists.

I'm wondering if there's a way we can automatically run fixers as part of a build if Prepare() fails, to recover the build.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.