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

actions-permissions/monitor/setup.sh

Lines 93 to 103 in 5802518

	# wait for mitmdump to start and generate CA certificate
	counter=0
	while [ ! -f /home/mitmproxyuser/.mitmproxy/mitmproxy-ca-cert.pem ]
	do
	echo "waiting for mitmdump to generate the certificate..."
	sleep 1
	counter=$((counter+1))
	if [ $counter -gt 10 ]; then
	exit 1
	fi
	done

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

actions-permissions/monitor/setup.sh

Lines 120 to 123 in 5802518

	sudo iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner mitmproxyuser --dport 80 -j REDIRECT --to-port 8080
	sudo iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner mitmproxyuser --dport 443 -j REDIRECT --to-port 8080
	sudo ip6tables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner mitmproxyuser --dport 80 -j REDIRECT --to-port 8080
	sudo ip6tables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner mitmproxyuser --dport 443 -j REDIRECT --to-port 8080

But it bails out early if the request is not to github.com or doesn't contain token_id

actions-permissions/monitor/mitm_plugin.py

Lines 535 to 542 in 5802518

	if self.contains_token(v, ctx.options.token):
	if hostname in self.ip_map or hostname in self.dns_map:
	permissions = self.get_permission(
	url_parts.path, flow.request.method, parse_qs(parsed_url.query))
	self.write_json(permissions, flow.request.method, hostname, url_parts.path)
	elif self.id_token_request_token and self.contains_token(v, self.id_token_request_token):
	if self.id_token_request_url and flow.request.method == 'GET' and hostname == self.id_token_request_url.hostname.lower() and url_parts.path.lower() == self.id_token_request_url.path.lower():
	self.write_json([('id-token', 'write')], flow.request.method, hostname, url_parts.path)

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.

actions-permissions/monitor/setup.sh

Line 97 in 1eeeb2e

while [ ! -f /home/mitmproxyuser/.mitmproxy/mitmproxy-ca-cert.pem ]

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