Not compatible with self-hosted runners ?

[Gby56]

I wanted to try the action, but a few weird bugs showed up. I was surprised to see mitmproxy used !

Sometimes the setup-python action fails completely, not sure if it's the proxy that is causing the timeout, I'm not sure what's the scope of the mitmproxy, I guess it's intercepting everything.

Request timeout: /github-production-release-asset-2e65be/250077933/90f0e4ab-cf53-462f-89bc-7b2df1bbc17b?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIxxxx%2F20230627%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230627T071226Z&X-Amz-Expires=300&X-Amz-Signature=d19f36c4xxxxx&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=250077933&response-content-disposition=attachment%3B%20filename%3Dpython-3.11.4-linux-20.04-x64.tar.gz&response-content-type=application%2Foctet-stream

And sometimes, the python setup works, but then it fails with the hashicorp vault action (probably a good thing, but I'm not quite sure how their client is accepting the certificate from mitmproxy...)

/runner/_work/_actions/hashicorp/vault-action/v2.6.0/dist/index.js:17324
                    throw new Error('The `onCancel` handler was attached after the promise settled.');
                          ^

Error: The `onCancel` handler was attached after the promise settled.
    at onCancel (/runner/_work/_actions/hashicorp/vault-action/v2.6.0/dist/index.js:17324:12)
    at makeRequest (/runner/_work/_actions/hashicorp/vault-action/v2.6.0/dist/index.js:3622:13)
    at Request.<anonymous> (/runner/_work/_actions/hashicorp/vault-action/v2.6.0/dist/index.js:3727:17)
    at Object.onceWrapper (node:events:642:26)
    at Request.emit (node:events:527:28)
    at Timeout.retry (/runner/_work/_actions/hashicorp/vault-action/v2.6.0/dist/index.js:5251:30)
    at listOnTimeout (node:internal/timers:559:17)
    at processTimers (node:internal/timers:502:7)

[JarLob]

That's odd. Thank you for the feedback! Indeed, it wasn't tested with self hosted runners, but I don't think there is a difference...

There is a 10 sec timeout in https://github.com/GitHubSecurityLab/actions-permissions/blob/58025184328c365edfeecd0a8e22d0bf71949fe8/monitor/setup.sh#L93-L103 for certificate generation. Not sure if this is the place where it sometimes fails and the timeout has to be increased. You can try rerunning the workflow with debug logging enabled.

The proxy intercepts everything that is sent to ports 80 and 443 https://github.com/GitHubSecurityLab/actions-permissions/blob/58025184328c365edfeecd0a8e22d0bf71949fe8/monitor/setup.sh#L120-L123 But it bails out early if the request is not to github.com or doesn't contain token_id https://github.com/GitHubSecurityLab/actions-permissions/blob/58025184328c365edfeecd0a8e22d0bf71949fe8/monitor/mitm_plugin.py#L535-L542

There can be an issue with a tool if there is a certificate pinning in place. I'll try to reproduce with the hashicorp action. If you can provide a simplified workflow for reproduction I would be grateful.

[Gby56]

I think the timeout you mentioned is purely in the setup, when it creates its own CA etc... I think my issue was purely when the request was going through the proxy, it's a bit hit and miss 🤔 For the hashicorp vault, I don't think there is pinning, but my intuition tells me maybe you can't inject the mitm CA certificate that easily ? I know for Python/Java it's fairly easy to find the used cacerts/keystore

[vedevilolivedev]

I discovered one issue with self-hosted is permissions, I disabled the timeout and found that the ca file was there, but since the user the runner was running as couldn't see it, it didn't think it was there. I added a "sudo" in front of that check, i.e. https://github.com/GitHubSecurityLab/actions-permissions/blob/1eeeb2e2ceb1dfca671ababa71dc4b6cd8fb24d2/monitor/setup.sh#L97 becomes while sudo [ ! -f /home/mitmproxyuser/.mitmproxy/mitmproxy-ca-cert.pem ] Then it starts and finishes install just fine. However, when trying to run another action that had to install packages (black, to be specific) it said

2023-07-05T21:46:22.4410547Z ERROR: Could not install packages due to an OSError: Could not find a suitable TLS CA certificate bundle, invalid path: /home/mitmproxyuser/.mitmproxy/mitmproxy-ca-cert.pem

The file definitely does exist and it confirmed itself that it was a permissions error at the end

Warning: Ignoring extra certs from /home/mitmproxyuser/.mitmproxy/mitmproxy-ca-cert.pem, load failed: error:0200100D:system library:fopen:Permission denied

This is on Ubuntu Jammy 22.04 on AWS