Re: security/py-mitmproxy: new port (version 10.3.0)

On Sun, 25 Aug 2024 15:09:56 +0200,
Klemens Nanni <kn@openbsd.org> wrote:
>
> I noticed that mitmweb does not respond to ^C/TERM, KILL was needed
> to end the process from the shell again.
>

Here a diff with patch which addressed that issue.

diff --git security/mitmproxy/Makefile security/mitmproxy/Makefile
index 656d8cb95fd..85465edff63 100644
--- security/mitmproxy/Makefile
+++ security/mitmproxy/Makefile
@@ -1,6 +1,7 @@
COMMENT = interactive intercepting HTTP proxy

MODPY_EGG_VERSION = 10.4.2
+REVISION = 0

DISTNAME = mitmproxy-${MODPY_EGG_VERSION}

diff --git security/mitmproxy/patches/patch-mitmproxy_tools_main_py security/mitmproxy/patches/patch-mitmproxy_tools_main_py
new file mode 100644
index 00000000000..41d20c5d779
--- /dev/null
+++ security/mitmproxy/patches/patch-mitmproxy_tools_main_py
@@ -0,0 +1,25 @@
+https://github.com/mitmproxy/mitmproxy/pull/7130
+Index: mitmproxy/tools/main.py
+--- mitmproxy/tools/main.py.orig
++++ mitmproxy/tools/main.py
+@@ -116,10 +116,16 @@ def run(
+ def _sigterm(*_):
+ loop.call_soon_threadsafe(master.shutdown)
+
+- # We can't use loop.add_signal_handler because that's not available on Windows' Proactorloop,
+- # but signal.signal just works fine for our purposes.
+- signal.signal(signal.SIGINT, _sigint)
+- signal.signal(signal.SIGTERM, _sigterm)
++ try:
++ # We use loop.add_signal_handler on supported platform to avoid stuck on signal
++ # See: https://github.com/mitmproxy/mitmproxy/issues/7128
++ loop.add_signal_handler(signal.SIGINT, _sigint)
++ loop.add_signal_handler(signal.SIGTERM, _sigterm)
++ except NotImplementedError:
++ # anyway, if platform hasn't got loop.add_signal_handler, use signal.signal
++ signal.signal(signal.SIGINT, _sigint)
++ signal.signal(signal.SIGTERM, _sigterm)
++
+ # to fix the issue mentioned https://github.com/mitmproxy/mitmproxy/issues/6744
+ # by setting SIGPIPE to SIG_IGN, the process will not terminate and continue to run
+ if hasattr(signal, "SIGPIPE"):


--
wbr, Kirill