Skip to content
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

Runner corrupts secrets containing backslashes #2089

Closed
redlizard opened this issue Aug 30, 2022 · 5 comments
Closed

Runner corrupts secrets containing backslashes #2089

redlizard opened this issue Aug 30, 2022 · 5 comments
Assignees
Labels
awaiting-customer-response bug Something isn't working Runner Bug Bug fix scope to the runner

Comments

@redlizard
Copy link

As of version 2.296.0, if the actions runner creates a docker container to execute an action which receives github secrets as environment variables, any backslash characters in the secret values get doubled. This results in the docker container receiving an incorrect value of the secret.

Commit 01fd044 escapes all command line arguments to docker commands by replacing double-quote and backslash character with an escape sequence, which includes github secrets. This would work on unix, but the action runner dotnet framework uses the windows-native escape scheme, in which \\ is not an escape sequence in most conditions. Thus, escaped backslashes in secret values are not interpreted correctly when starting a docker process using the resulting command line arguments.

@redlizard redlizard added the bug Something isn't working label Aug 30, 2022
@thboop
Copy link
Collaborator

thboop commented Aug 30, 2022

Hey @redlizard thank you for the report we are digging into this issue.

Can you confirm if you are seeing this in container actions or just job/service containers.

Do you have an example workflow yaml or action yaml you can provide?

@redlizard
Copy link
Author

I am indeed seeing this in container actions, not service containers. I do not have a prepared testcase, but I could write one if necessary.

I do not think your solution posted here is quite correct. According to this specification, which I think also applies to the dotnet process-spawning procedures, \\ is an escape sequence as long as it directly preceeds a quote character; your solution does not implement this, and therefore reopens the problem fixed in #2062. Specifically, that means that in any sequence of backslash characters followed by a double-quote character, the backslashes act as escape characters; whereas in any other context, they are regular characters.

I have not checked that this specification does in fact apply to the process creation call used by the actions runner; it is only my best guess based on observed behavior so car. Caveat lector.

@nikola-jokic
Copy link
Contributor

Hey @redlizard,

Please provide one testcase, so we can better understand the issue. This PR aims to solve this issue when passing environment variables to the docker. Please, let us know if that solves your issue ☺️

@nikola-jokic nikola-jokic added Runner Bug Bug fix scope to the runner awaiting-customer-response labels Sep 5, 2022
@redlizard
Copy link
Author

I think #2091 solved it, and #2108 solved it better. I have not yet had the opportunity to test either of them, but it looks good to me on first glance.

@nikola-jokic
Copy link
Contributor

Thank you, @redlizard, I will close this issue now but feel free to re-open it or submit another one if you see any problems with this ☺️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting-customer-response bug Something isn't working Runner Bug Bug fix scope to the runner
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants