-
Notifications
You must be signed in to change notification settings - Fork 319
docker_run_flags: Shellescape any provided values #811
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
Conversation
docker_run_flags is a functionBreaking changes to this file WILL impact these 1 modules (exact match):Breaking changes to this file MAY impact these 6 modules (near match):This module is declared in 6 of 579 indexed public
|
Hey 👋 Can you set this PR to ready for review? thanks! |
I am wondering if the CI failures are relevant… Like |
@smortex - i'll take a closer look at this tomorrow. Seems odd that all of the failures here are for Windows and they don't seem to be on the nightly tests either.. |
@neomilium @chelnak I added a commit that seems to help… but escaping on windows is total nonsense and I am sure of nothing 😱 Some windows node pass, the one failing seems to fail earlier than the code added / changed here and the failures might be the result of some external service not being reliable… maybe? |
subject = args[0] | ||
|
||
if self['facts'] && self['facts']['os']['family'] == 'windows' | ||
%("#{subject.gsub('"', '\\"')}") |
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.
is that just because the shellescape function is designed for linux? what about patching https://github.com/puppetlabs/puppetlabs-stdlib/blob/main/lib/puppet/parser/functions/shell_escape.rb 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.
The more I am thinking about it, the more I am concerned about cmd.exe escaping vs. powershell escaping: they seem to be different in incompatible ways:
Maybe the stdlib should have 3 shell escape functions: shell_escape
, powershell_escape
and cmd_escape
, then modules could have a local escape function which call the right escape function on windows depending on what the module is using?
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.
that sounds like a good idea
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.
puppetlabs/puppetlabs-stdlib#1235 was merged in stdlib. When we have a new release with this code, we will be able to move on with this PR.
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.
@smortex Looks like these changes are available as of v8.2.0 of stdlib
Happy to work with someone to get this through.
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.
Awesome! I added a commit to rely on this new code. Let's see what the CI think about it 😉
Ruby Shellwords#shellescape "Escapes a string so that it can be safely used in a Bourne shell command line". This is fine for a UNIX like operating system, but windows does not complies with this. Attempt to fix CI by manually "escaping" strings on windows (i.e. quote them and escape quotes with a backslash), and relying on shellescape for other operating systems.
At the cost of one more function call, we gain in readability and what the docker::escape functions is more straightforward.
Escaped strings should not be quotted. While here, also rework the way networks are escaped: the previous code was generating invalid parameters.
@neomilium have you had a chance to see if the issue you originally tried to fix with this PR is indeed fixed with all these changes? |
@smortex @chelnak @bastelfreak - why has stdlib been raised to min v8.2.0 in the pull request? That is very high and will have breaking impact when combined with a number of other available modules |
Because we had to add escape functions for windows in the stdlib: see this discussion above and puppetlabs/puppetlabs-stdlib#1235. |
@smortex @bastelfreak How do you both feel about moving forward with this PR? Pending test failures which I think may be transient, I think it is good. Though I do wonder if it is a breaking change due to the higher requirements of What are your thoughts? |
I've chatted with @canihavethisone around some of the concerns raised in the comment above. I personally think This is also an issue that we will probably hit again with other modules. In order to take advantage of newer features in |
My concern is that the major fast forward of the stdlib dependency may have significant impact for users of this module in deployments alongside other modules that haven't caught up yet. I recon a good metric would be how many popular modules still have stdlib pinned lower than v.8x, and weigh that against the urgency of this change or if it can be merged when 8x is more commonly scoped. I understand there will be diversity of opinions but think its worth considering. |
How to define "popular modules"? |
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.
How do you both feel about moving forward with this PR?
My position is that we have tooling to check module versions and that roles and profile in a control-repo are working as expected (e.g. using onceover), so do not worry much about bumping versions. I would not expect users to blindly update things, skipping major versions and assume everything will be fine witout testing .
@chelnak @smortex |
Here's a list of all the Forge modules that pin their stdlib dependencies to <8.x, sorted by download count (a weak correlation to popularity.) Notice that many of them are deprecated. |
Hi @neomilium. After careful evaluation of your PR, I'm happy to inform you that we are ready to go ahead and merge it. Thanks for your contribution! We also noted that there are some concerns about this PR, such as the one raised by @canihavethisone. We have considered the potential impact of these changes and we have decided to still go forward with it. While it is true that there may be some compatibility issues with a few non-supported modules, we also have noted that this change may be important for one of our current security enhancement projects and, as such, either this or something very similar was bound to be implemented sooner or later. We are sorry if this causes any inconvenience. |
This PR will be temporarily reverted until a release can be cut. Then it will be reinstated. This process is done to follow with standard best practices. |
Hey @neomilium. We are sorry for this inconvenience but we had to revert your PR in order to follow best practices when releasing a new version of our module, by making a minor release prior to a backwards incompatible one. We could re-implement it but I'm afraid it would appear under our name. Could you reopen your branch under a new PR so that we can merge and give proper credit to all contributors? |
Rebasing or cherry-picking the commits would maintain the original commit authors. |
docker_run_flags: Shellescape any provided values
When passing an environment variable with special characters, it can broke the script or produce unexpected behavior.
I encountered two of them:
$
is in environment variable, its interpolated as a variable"
is in environment variable, it broke the end of string, so the scriptThis PR contains a commit to escape any value that will be pushed in the docker start script.