mhils

> Has there been progress in improving that aspect during the LLM phase of the rewrite?

I'd say so! We aim to have our replacements to be `forbid(unsafe)` - no raw pointers - outside of `ffi.rs`. Of course it's tricky because we need to interoperate with existing C code, but we've been trying to come up with abstractions that make this a bit more ergonomic (https://github.com/google/safer_cffi).

> didn't say they did anything with a VLM to check the output vs the original library

Assuming VLM stands for vision–language model: We validated that all pixels are bit-identical across those 30M GIFs. So we didn't need a language model for that, we just compared expected and actual pixel buffers for strict equality. :)

There is a blog post on (the early baby steps of) that: https://bughunters.google.com/blog/scaling-memory-safety. We have multiple AI-assisted Rust rewrites running in production now.

(Full disclosure: I am one of the coauthors)

FWIW I agree that the Rust way is nicer, but I can't impose the Rust way on Python. I guess the secret hack is to use PyO3, which pdoc supports quite well. ;)

pdoc3 is not pdoc, see https://github.com/mitmproxy/pdoc?tab=readme-ov-file#pdoc-vs....

Let me try to explain why it is that way: First, it's consistent with Python functions. The docstring for functions is below the signature as well. Second, consider a file with only a docstring and then a variable declaration. Here it would be ambiguous if that's the module or the variable docstring. Finally, this behavior is consistent with other tools (and failed standardization efforts) in the space. So yeah - I share your sentiment, but I think it's the most pragmatic approach for pdoc. :)

pdoc maintainer here. Pleasant surprise to see us on HN again, and happy to answer any questions! :)

I'd say neither fork as made great strides since then, but I'm also biased here as the maintainer of pdoc.

There is no pdoc-specific library for link checking as far as I'm aware. It's all plain HTML though, so you can use a more general tool like https://lychee.cli.rs/. :)

Congrats on the seccomp-based interception, that's a really neat way to solve this problem! We did some BPF_PROG_TYPE_CGROUP_SOCK eBPF shenanigans in mitmproxy for redirection, but that doesn't work with containers at all. Cool to see that intercepting all relevant syscalls works that well.

This is really cool, thank you for sharing! We've built a similar feature for mitmproxy lately, but with different tradeoffs. Our approach does require root and we don't have automated certificate install (yet), but we don't require apps to run in a dedicated namespace (so you can capture already-running processes). Super awesome to see this now, excited to dive into the code and see how you do TCP reassembly etc. :)

> so you have to configure your program to use a proxy server.

That's not true for local capture mode: https://mitmproxy.org/posts/local-capture/linux/. :)

Fully reproducible builds would of course be nicer from a security standpoint, but attestations have vastly lower implementation costs and scale much better while still raising the bar meaningfully.

One of the main promises of HTTP/3 is better performance under worse network conditions (e.g. no head-of-line blocking as in HTTP/2, connection migration, 0-RTT). For all of that HTTP/3 between client and proxy is really great. HTTP/3 between proxy and server is not required for that.

Thank you for your work on Hickory! It's super exciting to see how PyO3's Python <-> Rust interop enables us to use a production-grade DNS library with Hickory and also a really solid user-space networking stack with smoltcp. These things wouldn't be available in Python otherwise.

There's OCSP Must-Staple, which makes MITM without stapling impossible. That is, if the client implements it and does not fail open. :)

It does. It also optionally supports notifications if someone messages you while you have all tabs closed (using https://developer.mozilla.org/en-US/docs/Web/API/Notificatio...).

TIL this goes back to 2006, how cool! We nowadays have a much simpler version as a mitmproxy example: https://github.com/mitmproxy/mitmproxy/blob/main/examples/ad.... Although it obviously does not work as well anymore with everything being HTTPS nowadays (unless you trust the cert of course). :)

I can answer this as one of the mitmproxy devs: We're doing this for 10+ years as FOSS, we're a relatively well-known project (so lots of eyes hopefully), our software has absolutely zero telemetry / phone home functionality, and we're developing under our real names. We also have relevant backgrounds in either the security industry and academia, and absolutely no plans to monetize mitmproxy.

Does that make it guaranteed to be safe? Not really. I'd personally trust our TLS stack over most IoT TLS implementations, but Chrome/Firefox/Safari will do a better job at e.g. revocation checking. That being said, I'd argue that this is unlikely to be the weakest link in your threat model.

Performance of our HTTP/3 stack is not very good yet, and the benefits of HTTP/3 don't play out in this particular example. :)

Asking for a release date is a perfectly reasonable request! My response was highly influenced by the context. I came back with "email me for a support contract" because 1) I previously stated in the thread that we will not ship a patch release for this[^1] and 2) the commenter emphasized the impact on their paying customers. So this was all I had to add there. I agree that I could have phrased this more nicely, but I personally don't feel my reply was totally over the top.

[^1]: the CVE itself is bogus and we don't use that part of the dependency.

We transitioned from S3 to R2 for downloads.mitmproxy.org because egress got prohibitively expensive for a hobby ($300/month). CI for 9.x still points to the old infrastructure. This does not mean we couldn't ship a patch release right now, but it would take me 1-2 hours.

The vulnerability in question is in parts not used by mitmproxy. We looked at it when it came out, and I'd even say it's more of a bug than a security vulnerability. Again, in either case it's not used by mitmproxy.

OP here. To be clear, I don't mind the release question at all, it's valid! But the context should be along the lines of "we have an interest in this, how can we help make it happen" (contributions or $) and not "you are causing problems for our customers". I don't want the requestor to have a miserable time because of a badly-worded comment, I want large companies to have a healthy relationship with FOSS.

Not supporting GPC (the DNT successor) directly contradicts the "respecting users" marketing fluff. I suspect the main reason why there is a "reject all" button is that Cloudflare folks rightly figured out that they are too big to get away with not providing one. Otherwise noyb.eu will say hello. OneTrust etc. are doing the same, there's nothing more user respecting about this solution.

If Cloudflare is serious about privacy here, they should at least respect GPC and not provide customers with an option to disable it.

Fantastic work, kudos! OIDC auth is so much nicer compared to any ad-hoc secrets management. Thank you for dealing with JWT for us. :)

As a small suggestion, it may make sense to move the "Create a token for ..." button to the new publishing page on PyPI? This way both options would be next to each other. I went straight to the settings page after reading your blog post, and was initially confused to only find the old token option there. Having both at the same place would maybe be more straightforward.

The note in the official Python documentation was only added in September 2022 [1], so no wonder this comes as a surprise to many!

[1] https://github.com/python/cpython/commit/6281affee6423296893...

I don't think anyone argues against treating them as bugs (and fixing them), they just shouldn't get as much special attention as they do.

This really shouldn't be the case. What kind of client are you using? Could you open an issue over at https://github.com/mitmproxy/mitmproxy/issues please?

Our WireGuard mode is entirely user space and works on all operating systems mitmproxy runs on. :)

What do you mean by "on the basis"? :)

Suppose you have an Android device for which you want to see all traffic. You could configure an HTTP proxy in your system settings, but this does not capture any UDP-based protocols. Additionally, apps may choose to ignore the proxy settings and it's hard to tell if they do. To overcome these shortcomings, we now have WireGuard mode: Mitmproxy spawns a WireGuard server on startup (instead of an HTTP proxy listener). Now you don't set a proxy on your device, but you configure your device to use WireGuard with a config that sends all traffic to mitmproxy. mitmproxy then transparently intercepts all requests that are coming through that WireGuard tunnel (the device still needs to trust the mitmproxy CA). Put differently, instead of using an explicit proxy configuration or something like iptables to route packets to mitmproxy, you use a VPN (WireGuard). The benefits are:

  - You can intercept/modify UDP, in particular DNS.
  - You avoid the "apps ignore proxy settings" problem.
  - On Android specifically, the WireGuard app allows you to only proxy specific apps (not possible with a global proxy config)

Does that make more sense now? We also have a bit more documentation at https://docs.mitmproxy.org/stable/concepts-modes/#wireguard-....