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
Regression due to #31237: Local paths not valid return values any more #31404
Comments
Hi @dr-yd, Thanks for filing the issue. I'm not sure what exactly has changed from that commit, mostly because I surprised that the use case you've shown previously worked. The registry protocol was defined such that a path returned in
Arbitrary protocol switching is specifically something that was not to be allowed, and the referenced patch was part of the security fixes from upstream. As this was being handled incorrectly before, and the fixes are just dis-allowing the incorrect protocol switch to evaluate local files, I have a feeling that this portion of the protocol was actually never implemented in As to the issue of a regression, that will be something we have to review. Since it's also not working correctly now per the documentation (only the protocol switch was fixed, no changes were made to the redirection mechanism), and the old behavior was contrary to the security guidelines, the correct fix may be to implement the protocol as specified. Thanks! |
Hi @jbardin , thanks for commenting. Interesting to see that we were using an unintended functionality - I just followed the sentence from the documentation that I quoted and it worked. You answer is a bit alarming. Does it mean that switching to git (== SSH) protocol is against your intentions as well? That would be a huge problem for us. Background: We have a central If switching to git / SSH is allowable, what about adding a |
Oh yes, while arbitrary protocol switching is something that is not desired for security reasons (having a remote system force the loading of any local file could be combined with other attack vectors), we did try to maintain the documented protocol combinations for compatibility. Switching to |
Ah, that's great to hear - so at least the pipelines won't break in the future. For local development, there are workarounds (e.g. running a webserver locally and just serving local files from there) but if you come to the conclusion that there should be some official way to reference local files, that would of course be preferable from my POV. Since it's not a pressing issue, maybe you can find the time to discuss this and update the thread for one of the next releases. Thanks! |
Hi @jbardin ! We've recently bumped into some issues when attempting to make a protocol switch from For context, we're hosting vanity redirects through a static website towards GitHub sources that hold our Terraform modules. The
|
For git, the response must be something like
Re: Topic, I only recently noticed that the |
Terraform Version
Working: v1.2.2
Broken:
Same behavior in v1.2.4.
Terraform Configuration Files
n/a
Debug Output
Debug output available upon request directly to maintainers but should be easy to reproduce.
Expected Behavior
Returning a local path from an HTTP module source should be possible.
Actual Behavior
Behavior as expected in v1.2.2. In v1.2.3, sample output:
Steps to Reproduce
Return a local path as a module location from an HTTP module source.
Additional Context
We're using a service that pins Terraform module versions depending on the repository and branch. When run locally for testing, local module paths are returned as the location. (To pipelines, git locations are returned, this works.) Pull #31237 makes this impossible. If there's a syntax to reference local paths currently, we're unaware of it.
Furthermore, the documentation is now incorrect as it states "In either case, the result is interpreted as another module source address using one of the forms documented elsewhere on this page." The local path location is documented on the same page.
https://www.terraform.io/language/modules/sources
References
#31237
The text was updated successfully, but these errors were encountered: