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. ;)
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. :)
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. :)
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.
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.
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.