mitmproxy 10.1.1

[mhils]

Created with brew bump-formula-pr.

• resource blocks have been checked for updates.

[mhils]

Hi folks! filing this early to get some feedback on what we should do with https://pypi.org/project/mitmproxy-macos/. In short, mitmproxy-macos is a new dependency that includes a precompiled macOS System Network Extension (written in Swift). Building from source isn't straightforward here because the system extension needs to be signed & notarized by Apple to work. How does that fit with Homebrew?

[chenrui333]

Hi folks! filing this early to get some feedback on what we should do with https://pypi.org/project/mitmproxy-macos/. In short, mitmproxy-macos is a new dependency that includes a precompiled macOS System Network Extension (written in Swift). Building from source isn't straightforward here because the system extension needs to be signed & notarized by Apple to work. How does that fit with Homebrew?

If there is source code available, we should build from source for it.

[mhils]

If there is source code available, we should build from source for it.

There absolutely is:

• Sources: https://github.com/mitmproxy/mitmproxy_rs/tree/main/mitmproxy-macos
• CI for builds: https://github.com/mitmproxy/mitmproxy_rs/blob/0.3.7/.github/workflows/ci.yml#L107-L170
• Swift app build + signing: https://github.com/mitmproxy/mitmproxy_rs/blob/main/.github/scripts/build-macos-redirector.sh

The tricky part is that the system extension must be signed and notarized with the correct entitlements/provisioning profile, otherwise it will not work. I've tried searching the Homebrew issue tracker for similar cases, but did not find any.

[SMillerDev]

The tricky part is that the system extension must be signed and notarized with the correct entitlements/provisioning profile, otherwise it will not work.

Then it won't work for anyone using the Homebrew/core version unfortunately. Homebrew applies adhoc signatures when installing on ARM, but unfortunately we can't notarise anything.

[mhils]

Thanks @SMillerDev! Is there a path forward for us to get this supported in the Homebrew/core version? We've been suggesting brew install mitmproxy as the main installation method for years, and there are tons of online resources referencing that. It would be fantastic if we could keep it that way. Is a Python source distribution that bundles an open-source CI-built notarized system extension acceptable for Homebrew/core?

[mhils]

I've updated this PR as per my last comment - mitmproxy-macos now is a Python "source" distribution that contains the precompiled notarized system extension. Please let me know if that's an acceptable approach. I've considered the following alternatives:

1. One possible solution would be to move mitmproxy to a custom tap or distribute it as a cask. We'd really like to avoid that because brew install mitmproxy is not only right on mitmproxy.org, but also in tons of external blog posts etc. It'd be a major support headache for us.
2. Instead of shipping mitmproxy with a precompiled binary, we can of course keep the installation clean and dynamically download the system extension at runtime. I feel this does not really change the outcome for users, but it would adhere to a strict reading of the current Homebrew policies. Right now we do not have any telemetry in mitmproxy at all, so I'd be a bit sad to deviate from that. But from our end we'd still prefer that over 1).
3. If it would help our case, we'd be happy to also provide SLSA provenance attestation for the binaries and somehow validate that in our formula. SLSA provenance would at least show that the binaries are built straight from our sources in GitHub Actions, and are not modified in any way. It's a bit of work to set up for us, but if that'd help, we'd be happy to implement that.
4. For completeness, I'd like to mention again that we would be extremely happy to just provide sources and Homebrew signs + notarizes our system extension. I understand that this is not possible right now, but I'd like to re-emphasize that we come with good intentions and this would be our preferred approach.

Thanks y'all for your support with Homebrew! 🍰

[MikeMcQuaid]

1. We'd really like to avoid that because brew install mitmproxy is not only right on mitmproxy.org, but also in tons of external blog posts etc. It'd be a major support headache for us.

Note: if mitmproxy turns into a cask and the formula is removed: brew install mitmproxy will still just work.

This feels like it would probably be the best solution to me, at least for macOS.

[MikeMcQuaid]

@mhils just wanted to specifically call out though: thanks so much for your understanding and kind, measured tone throughout. It's much appreciated (and can sometimes be rare). You rock! ❤️

[mhils]

Thank you for the kind words - appreciate y'all. 😊

Not the recommendation I was hoping for, but I understand the reasoning behind it. We'll probably need to a bit of time on our end to come up with a macOS binary distribution, but will go for that. Thanks again for the quick replies! :)

[mhils]

Thank y'all for bearing with us. :) I've just opened Homebrew/homebrew-cask#159283 to add the cask.