14 Commits (add-missing-variable-loading)

Author	SHA1	Message	Date
Radek Simko	0fe906fa8c	make copyrightfix	2 months ago
James Bardin	f78adc889e	add wrappers to verify file function results ... Create wrappers to inject function results verification into all the filesystem function implementations.	11 months ago
James Bardin	5ccb3c7c7a	templatefile need to be unmarked for TypeFunc ... The templatefile function actually calls the full renderer within the TypeFunc to determine what the resulting might be, but that also requires unmarking the top-level of the vars map to strip marks even though the value is unused.	1 year ago
James Bardin	833b07436f	template variables may be entirely unknown ... While the evaluator can deal with unknown template variables, if the entire map of variables is unknown, we can't create the map and need to short-circuit the call.	1 year ago
James Bardin	651a80fb57	deal with unknown marked vals in fs funcs ... Filesystem functions accepts marked values, and must also deal with unknowns.	1 year ago
James Bardin	a51be5e930	lang functions must deal with unknown and marks ... You can't deal with marks in a function without also dealing with unknown. If AllowMarked is true, but AllowKnown is not, the caller will short-circuit the evaluation with an unknown, without being able to deal with marks from all arguments.	1 year ago
Martin Atkins	9dd28fc2e5	funcs: Don't panic if templatefile path is sensitive ... Previously we were partially propagating any marks from the path, but not going all the way so we still ran into trouble when trying to use the string containing the file contents. Now we'll have loadTmpl also return the marks it had to read through to actually parse the template, and then we'll use those (instead of the original path marks) to mark the result. In practice the pathMarks and the tmplMarks should always match today, but this is intentionally structured to make the data flow clearer -- the marks always travel along with whatever they related to -- so we're less likely to break this accidentally under future maintenence.	2 years ago
Martin Atkins	edf335e7eb	lang/funcs: Experimental "templatestring" function ... This function complements the existing "templatefile" to deal with the unusual situation of rendering a template that comes from somewhere outside of the current module's source code, such as from a data resource result. We have some historical experience with the now-deprecated hashicorp/template provider and its template_file data source, where we found that new authors would find it via web search and assume it was "the way" to render templates in Terraform, and then get frustrated dealing with the confusing situation of writing a string template that generates another string template for a second round of template rendering. To try to support those who have this unusual need without creating another attractive nuisance that would derail new authors, this function imposes the artificial extra rule that its template argument may only be populated using a single reference to a symbol defined elsewhere in the same module. This is intended to entice folks trying to use this function for something other than its intended purpose to refer to its documentation (once written) and then hopefully learn what other Terraform language feature they ought to have used instead. The syntax restriction only goes one level deep, so particularly-determined authors can still intentionally misuse this function by adding one level of indirection, such as by building template source code in a local value and then passing that local value as the template argument. The restriction is in place only to reduce the chances of someone _misunderstanding_ the purpose of this function; we don't intend to prevent someone from actively deciding to misuse it, if they have a good reason to do so. This new function inherits the same restriction as templatefile where it does not allow recursively calling other template-rendering functions. This is to dissuade from trying to use Terraform templates "at large", since Terraform's template language is not designed for such uses. It would be better to build a Terraform provider that wraps a more featureful template system like Gonja if someone really does need advanced templating, beyond Terraform's basic goals of being able to build small configuration files, etc. Because this function's intended purpose is rendering templates obtained from elsewhere, this function also blocks calls to any of Terraform's functions that would read from the filesystem of the computer where Terraform is running. This is a small additional measure of isolation to reduce the risk of an attacker somehow modifying a dynamically-fetched template to inspire Terraform to write sensitive data from the host computer into a location accessible to the same attacker, or similar. This is currently only a language experiment and so will not yet be available in stable releases of Terraform. Before stabilizing this and committing to supporting it indefinitely we'll want to gather feedback on whether this function actually meets the intended narrow set of use-cases around dynamic template rendering.	2 years ago
Martin Atkins	d1df979115	lang: Expose built-in functions under core:: namespace ... This essentially doubles up the registrations for all of the built-in functions to have both non-namespaced and core::-namespaced versions of each function. This is in preparation for later commits introducing other namespaces, such as a provider:: namespace which could hold functions that were contributed by providers that are currently in scope.	2 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Martin Atkins	e95f29bf9d	lang/funcs: fileexists slightly better "not a file" error message ... Previously we were just returning a string representation of the file mode, which spends more characters on the irrelevant permission bits that it does on the directory entry type, and is presented in a Unix-centric format that likely won't be familiar to the user of a Windows system. Instead, we'll recognize a few specific directory entry types that seem worth mentioning by name, and then use a generic message for the rest. The original motivation here was actually to deal with the fact that our tests for this function were previously not portable due to the error message leaking system-specific permission detail that are not relevant to the test. Rather than just directly addressing that portability problem, I took the opportunity to improve the error messages at the same time. However, because of that initial focus there are only actually tests here for the directory case. A test that tries to test any of these other file modes would not be portable and in some cases would require superuser access, so we'll just leave those cases untested for the moment since they weren't tested before anyway, and so we've not _lost_ any test coverage here.	4 years ago
Alisdair McDiarmid	5d7cb81c0c	lang: Redact sensitive values from function errors ... Some function errors include values derived from arguments. This commit is the result of a manual audit of these errors, which resulted in: - Adding a helper function to redact sensitive values; - Applying that helper function where errors include values derived from possibly-sensitive arguments; - Cleaning up other errors which need not include those values, or were otherwise incorrect.	4 years ago
Martin Atkins	cdd9464f9a	Move lang/ to internal/lang/ ... This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.	5 years ago