Chef: remote_file: make checksum more flexible

[docwhat]

Lots of sites use SHA1 or even MD5 for their checksums instead of SHA256.

It would be really handy if remote_file's checksum took an (optional) prefix to specify an alternative hash algorithm.

Examples:

• {md5}9fc0985096f7b55a2bb23ae2e5c7f618
• {sha1}816f9c83b9391525a3ae782557ddc8d50c227ad6
• {sha256}44c512f66b34f41911415defe3bb5438109dfbc5761ff212674c85913cc52281
• {sha512}388c56e26ce7c170a58b251f079f5b98c438cdab619bec23187c4a30ebcd0cf4d9908a41d58fbf7a0025bcd1ad86d119a8c919aea78deeeb1b3055d364096173

[lamont-granquist]

I think this is a dup of a request that we had in the old ticketing system and we probably should do this at some point.

We'd need to keep FIPS openssl and #3945 in mind, but I think this is orthogonal to that.

[jsarkar]

Any update or feature plan when sha1 and md5 support will be added to remote_file resource? I really need that. The project I am working for currently only have md5 and sha1 checksum.

[lamont-granquist]

I suspect we're not going to prioritize this any time soon. The kinds of people that pay us to get work done generally want FIPS compliance and want MD5 and SHA1 checksums ripped out of their infrastructure so that nobody can accidentally configure anything to use them. It would be accepted as a PR.

"Low priority" tagged tickets generally means that they'll be completely queue-starved by medium and high work ahead of them.

[klyonrad]

I suspect we're not going to prioritize this any time soon. The kinds of people that pay us to get work done generally want FIPS compliance and want MD5 and SHA1 checksums ripped out of their infrastructure

@lamont-granquist And what about SHA512 ?

[grv87]

The same problem. Source has only MD5 and SHA512 checksums, but no SHA256. Could SHA512 be prioritized upper?
I propose to add separate checksum_type property with default sha256