Closed baltpeter closed 1 year ago
We are already adding listeners to the process' stdout
in awaitMitmproxyEvent()
. I wasn't sure whether we could add another listener to record the events or whether multiple listeners would interfere.
The docs sound like that should work but weren't entirely clear.
So, I wrote a little test script. index.ts
:
import { execa } from 'execa';
(async () => {
const proc = execa('node', ['child.js']);
proc.stdout.addListener('data', (d) => console.log(1, d.toString()));
proc.stdout.addListener('data', (d) => console.log(2, d.toString()));
})();
child.js
:
const pause = (ms) => new Promise((res) => setTimeout(res, ms));
(async () => {
console.log('start');
await pause(1000);
console.log('end');
})();
Output:
1 start
2 start
1 end
2 end
So, yes, that is fine.
The mitmproxy script currently doesn't capture the hostnames in machine-readable format for TLS failures: https://github.com/tweaselORG/meta/issues/16#issuecomment-1602683111
The mitmproxy script currently doesn't capture the hostnames in machine-readable format for TLS failures: tweaselORG/meta#16 (comment)
Implemented. We now expose pretty much all the information mitmproxy gives us.
It would be useful to get access to the mitmproxy events, for example to know when the certificate pinning bypass failed. Currently, we read them but don't expose them to the user.
I need this for https://github.com/tweaselORG/meta/issues/16.