-
Notifications
You must be signed in to change notification settings - Fork 2k
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
template: disable sandboxed rendering on Windows #23432
Conversation
f549737
to
07efb52
Compare
91fba36
to
07efb52
Compare
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 think I understand where you're going with this, but the TaskTemplateManagerConfig
we're passing in is still having a ReaderFn
and RenderFn
set. By having those functions just empty return nil
, I think we end up not rendering at all because we never read anything. That should be detected by tests on Windows but doesn't seem to be?
I'd probably leave the TaskTemplateManagerConfig
constructor in place for both Windows and default, and have the ReaderFn
and RenderFn
on Windows just call os.Open/Read
and CT's own render function directly.
yeah these |
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.
yeah these ReaderFn and RenderFn functions are somewhat misleading. They are only ever used when the sandbox is enabled.
Oh right, what I was missing was that the ReaderFn
and RenderFn
functions are "factory" functions! (Which is hilarious because I wrote all this junk! 🤦) So they're getting called to return a nil
function for that configuration, which CT will accept and replace with its own default internal functions.
LGTM!
This removes helper winappcontainer and winexec helper code, since it is no longer needed after #23432
Following #23443, we no longer need to sandbox template rendering on Windows.
Relates to: #20585
Relates to: #20034
Internal ref: https://hashicorp.atlassian.net/browse/NET-9311
This is part of a solution outlined in RFC NMD-195.