-
Notifications
You must be signed in to change notification settings - Fork 9.7k
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
lang: New file-hashing functions #20115
Conversation
These all follow the pattern of creating a hash and converting it to a string using some encoding function, so we can write this implementation only once and parameterize it with a hash factory function and an encoding function. This also includes a new test for the sha512 function, which was previously missing a test and, it turns out, actually computing sha256 instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left one tiny doc note that doesn't block approval.
In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
b417b64
to
ef5dee0
Compare
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. |
In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob.
That approach relied on us being able to return raw binary data from
file(...)
. Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there wasa risk of string corruption in prior versions which we have avoided for 0.12 by requiring that
file(...)
be used only with UTF-8 text files.The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of
file(...)
.To avoid breaking these use-cases, here we introduce variants of the hash functions a with
file
prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions.This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when
file(...)
can and cannot read binary files, making the behavior of these various functions easier tounderstand in isolation. I also considered making functions that take base64 strings and hash that, for use in conjunction with
filebase64
, but it's not clear that much flexibility is required (so far we've been doing this only to sync upstream blobs with local files) and it would cause some confusion of names given that some of these hash functions already producebase64
and so havebase64
in their names. Therefore this new set offile...
hash functions felt like the least bad of a set of non-ideal choices.This fixes #20098, though will also require some documentation updates in providers to show the new idiom (using the relevant file hashing function directly) while also including a callout showing the old idiom for those still using Terraform 0.11.