-
Notifications
You must be signed in to change notification settings - Fork 258
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
Don't start ssh-agent
if it's already running
#108
base: master
Are you sure you want to change the base?
Conversation
e0146dc
to
442121e
Compare
@mpdude not sure if it's desired, but it would be welcome addition for composite actions. Also not sure about codestyle, line with |
You mean that this way, a sub-action (from composite actions) could start or add keys to the running agent without knowing whether the main action started the agent or not? |
Yep! And it wouldn't remove keys that are already added, if ssh-agent is already started before the subaction. |
in CI, looks unrelated |
😿 |
3 similar comments
😿 |
😿 |
😿 |
Sorry it took me so long to get back to this. Two thoughts:
|
Ugh, missed you comment and was reminded about this PR by dependabot notification about the new action version, sorry.
Maybe I'm missing something, but IMHO all of these concerns are theoretical and not practical and could be fixed by setting explicit distinct |
What about the two env variables If we say that a correctly started agent requires those to be set, we could also avoid starting the agent in case both are present. On the other hand, what if Regarding the shutdown phase: Would it be correct to terminate the agent even if we did not start it? How could we tell if that was the case? |
const authSock = core.getInput('ssh-auth-sock');
spawnSync(sshAdd, ['-l'], { env: { SSH_AUTH_SOCK: authSock || process.env.SSH_AUTH_SOCK } })
const sshAgentArgs = (authSock && authSock.length > 0) ? ['-a', authSock] : [];
child_process.execFileSync(sshAgent, sshAgentArgs) so
And after we're always setting
AFAICS there is no shutdown phase, so all the agents keep running until GHA job is finished? |
😿 |
This allows to run the action multiple times to add multiple keys without removing already added ones.
We need to fix the SSH keys shipped with this action: https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ But, we have another issue (#108) with regards to host keys: On self-hosted runners which are not ephemeral the known_host file fills up with repeated entries, because every action run adds a new line with the same host keys. Also, on those machines, the old key will still be in the `known_hosts` file. IMHO this action should not be repsonsible for shipping SSH host keys, that's too much responsibility. This section in the code is a leftover from early days when GitHub provided runners did not include SSH keys at all. For a long time already, GH takes care of placing their SSH keys in their runner images. For self-hosted runners, those people setting up the runner should fetch and verify SSH keys themselves and put it into the `known_hosts` file. I know this is a breaking change and is going to annoy users. But on the other hand, there is no better opportunity to drop this feature than with an emergency-style key revocation as today. Closes #106, closes #129, closes #169, closes #170, closes #172.
😿 |
This allows to run the action multiple times to add multiple keys
without removing already added ones.
Test run: https://github.com/ojab/ssh-agent/runs/5110810177, both keys are added.