morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #8078] [Feature] Accept mitmproxy 12.3.x in the native mitmproxy capture adapter #4668

New issue

Open

opened 2026-10-31 00:52:13 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-31 00:52:13 +00:00

Owner

Originally created by @ristoxy on GitHub (Oct 30, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8078

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Setup, packaging, or upgrade

Current limitation

bridge/mitmproxy/capture.py accepts exactly mitmproxy 12.2.3 (PROFILE = "12.2.3", decode() rejects any other version.VERSION). Because mitmproxy is bring-your-own, callers must keep 12.2.3 installed, and its upper bounds hold known-vulnerable dependencies in the same environment:

mitmproxy 12.2.3 bound	Advisory	Fixed in
`Brotli<=1.2.0`	GHSA-9v8h-qqgm-4m35 / CVE-2026-111497 (critical)	1.2.1
`cryptography<=48.1`	GHSA-jwv3-5hgf-82ww, GHSA-m2h6-j472-rp4c, GHSA-g6cj-pr64-35w5	49.0.0 / 50.0.0
`msgpack<=1.1.2`	GHSA-6v7p-g79w-8964, GHSA-j586-36cw-2gc2	1.2.1 / 1.2.3

mitmproxy 12.3.1 (2026-10-25) allows Brotli 1.2.1 and cryptography up to 50.0.2 and no longer depends on msgpack.

Desired outcome and success criteria

The offline native adapter accepts mitmproxy 12.3.1 (or a verified 12.3.x profile) and reports that version in its decoder identity, with the same decoded output as under 12.2.3.

Expected interaction with targets

Read existing files or captured data

Verification available so far

I have a prototype or observed results

Verification details

Tested against main at 317bf3fe235e655b2d752d3be261cc0da7d00f2b:

mitmproxy/io/tnetstring.py and mitmproxy/io/compat.py are byte-identical between tags v12.2.3 and v12.3.1; FLOW_FORMAT_VERSION is 21 in both.
Two flows (mitmproxy.test.tflow.tflow(resp=True) and tflow(resp=True, err=False)) were written once with each version's FlowWriter. Each file was decoded with the unchanged capture.decode() under real mitmproxy 12.2.3 and under 12.3.1, with only PROFILE set to the running version. The decoded JSON was byte-identical across both versions for both files, with decoder.version normalized.

import importlib.util, json, sys
from mitmproxy import version

src, mode, path = sys.argv[1:4]  # path to bridge/mitmproxy/capture.py, write|decode, flow file
if mode == "write":
    from mitmproxy import io
    from mitmproxy.test import tflow
    with open(path, "wb") as f:
        w = io.FlowWriter(f)
        w.add(tflow.tflow(resp=True))
        w.add(tflow.tflow(resp=True, err=False))
    sys.exit(0)
spec = importlib.util.spec_from_file_location("capture", src)
cap = importlib.util.module_from_spec(spec)
spec.loader.exec_module(cap)
cap.PROFILE = version.VERSION  # version gate only
out = cap.decode({"snapshot_path": path, "sensitive_values": []})
out["decoder"]["version"] = "<profile>"
print(json.dumps(out, sort_keys=True))

Alternatives considered

Keeping 12.2.3 with fixed dependencies is not possible: the resolver rejects Brotli 1.2.1, cryptography >48.1 and msgpack >1.1.2 alongside mitmproxy 12.2.3. Note that 12.3.1 still caps tornado<=6.5.10, so the tornado 6.6 advisories remain open until mitmproxy raises that bound; that is outside this request.

Possible direction

Bump PROFILE, MITMPROXY_CAPTURE_PROVIDER_IDENTITY.version and the pinned standalone archive in the Linux verification lane to 12.3.1, or accept a small set of verified versions.

Found and reproduced with Hermes Agent; reviewed before posting.

Originally created by @ristoxy on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8078 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Setup, packaging, or upgrade ### Current limitation `bridge/mitmproxy/capture.py` accepts exactly mitmproxy 12.2.3 (`PROFILE = "12.2.3"`, `decode()` rejects any other `version.VERSION`). Because mitmproxy is bring-your-own, callers must keep 12.2.3 installed, and its upper bounds hold known-vulnerable dependencies in the same environment: | mitmproxy 12.2.3 bound | Advisory | Fixed in | | --- | --- | --- | | `Brotli<=1.2.0` | GHSA-9v8h-qqgm-4m35 / CVE-2026-111497 (critical) | 1.2.1 | | `cryptography<=48.1` | GHSA-jwv3-5hgf-82ww, GHSA-m2h6-j472-rp4c, GHSA-g6cj-pr64-35w5 | 49.0.0 / 50.0.0 | | `msgpack<=1.1.2` | GHSA-6v7p-g79w-8964, GHSA-j586-36cw-2gc2 | 1.2.1 / 1.2.3 | mitmproxy 12.3.1 (2026-10-25) allows Brotli 1.2.1 and cryptography up to 50.0.2 and no longer depends on msgpack. ### Desired outcome and success criteria The offline native adapter accepts mitmproxy 12.3.1 (or a verified 12.3.x profile) and reports that version in its decoder identity, with the same decoded output as under 12.2.3. ### Expected interaction with targets Read existing files or captured data ### Verification available so far I have a prototype or observed results ### Verification details Tested against `main` at `317bf3fe235e655b2d752d3be261cc0da7d00f2b`: - `mitmproxy/io/tnetstring.py` and `mitmproxy/io/compat.py` are byte-identical between tags v12.2.3 and v12.3.1; `FLOW_FORMAT_VERSION` is 21 in both. - Two flows (`mitmproxy.test.tflow.tflow(resp=True)` and `tflow(resp=True, err=False)`) were written once with each version's `FlowWriter`. Each file was decoded with the unchanged `capture.decode()` under real mitmproxy 12.2.3 and under 12.3.1, with only `PROFILE` set to the running version. The decoded JSON was byte-identical across both versions for both files, with `decoder.version` normalized. ```python import importlib.util, json, sys from mitmproxy import version src, mode, path = sys.argv[1:4] # path to bridge/mitmproxy/capture.py, write|decode, flow file if mode == "write": from mitmproxy import io from mitmproxy.test import tflow with open(path, "wb") as f: w = io.FlowWriter(f) w.add(tflow.tflow(resp=True)) w.add(tflow.tflow(resp=True, err=False)) sys.exit(0) spec = importlib.util.spec_from_file_location("capture", src) cap = importlib.util.module_from_spec(spec) spec.loader.exec_module(cap) cap.PROFILE = version.VERSION # version gate only out = cap.decode({"snapshot_path": path, "sensitive_values": []}) out["decoder"]["version"] = "<profile>" print(json.dumps(out, sort_keys=True)) ``` ### Alternatives considered Keeping 12.2.3 with fixed dependencies is not possible: the resolver rejects Brotli 1.2.1, cryptography >48.1 and msgpack >1.1.2 alongside mitmproxy 12.2.3. Note that 12.3.1 still caps `tornado<=6.5.10`, so the tornado 6.6 advisories remain open until mitmproxy raises that bound; that is outside this request. ### Possible direction Bump `PROFILE`, `MITMPROXY_CAPTURE_PROVIDER_IDENTITY.version` and the pinned standalone archive in the Linux verification lane to 12.3.1, or accept a small set of verified versions. Found and reproduced with Hermes Agent; reviewed before posting.

bsakaguchi commented

2026-10-31 00:52:14 +00:00

Author

Owner

@xu91102 commented on GitHub (Oct 30, 2026):

I checked this on fresh main 317bf3fe235e655b2d752d3be261cc0da7d00f2b before implementation, using the real compiled inspect-web-network-capture CLI in an offline (--network none) Linux arm64 container with Node 24.22.1 and the official standalone mitmdump 12.2.3 / 12.3.1 archives.

Each real producer wrote an owned nonempty HTTP flow (binary request/response bodies, duplicate headers, an integer above JavaScript's safe-integer range and an extension), an empty capture, and a malformed negative control. Across 12 actual CLI calls:

Decoder 12.2.3 accepted the nonempty/empty files from both producers (four successes), reported its actual 12.2.3 identity, and rejected both malformed controls as invalid_input.
Decoder 12.3.1 refused all six calls with unsupported_provider; the concrete reason was Expected mitmproxy 12.2.3; observed 12.3.1.
Every source file's SHA-256 remained unchanged. An earlier slim-container run lacked ps and stopped at ownership preflight; that is retained as a harness prerequisite failure, not evidence of this version refusal.

I plan to admit only the two actually verified profiles, retain 12.2.3 compatibility, report the running decoder's exact version, and keep unverified versions/foreign decoder identities rejected. The existing offline/no-server/resource/cleanup boundaries stay in place. Search hits' actual relevant changes (#2876 headline indexing and #4924 HTTP/3 reset verification) do not update this version gate; I have not run foreign PR heads.

This does not verify the advisory claims in the issue, live TLS/HTTP3 capture, other mitmproxy versions, or other hosts. No product implementation has been made yet; original CLI outputs, tool archive hashes and immutable fixture hashes are retained.

Update: a publication-time recheck found #8088 by gyanu2507 (created 2026-10-30T03:02:45Z, before this comment). My initial search did not capture it. I read its actual production diff at head 325266aabb68e5b77bd79f7ad892df2621a0c81e: it changes the same native version gate/profile identity and SaveHar producer admission. My compatibility-set implementation is still an uncommitted local experiment and is now read-only HOLD; I will not submit a duplicate PR or package its legacy/HAR/test residuals as another contribution. The real 12.3.1 offline verifier completed 148 public cases locally, but there has been no independent Standards/Spec review, own source commit, fork push or upstream PR. I have not run #8088, and no source adoption or author credit is established. The earlier reproduction remains a record of main317, not an endorsement or runtime validation of the other PR. No issue close or reply to the other PR is being made.

@xu91102 commented on GitHub (Oct 30, 2026): I checked this on fresh main `317bf3fe235e655b2d752d3be261cc0da7d00f2b` before implementation, using the real compiled `inspect-web-network-capture` CLI in an offline (`--network none`) Linux arm64 container with Node 24.22.1 and the official standalone mitmdump 12.2.3 / 12.3.1 archives. Each real producer wrote an owned nonempty HTTP flow (binary request/response bodies, duplicate headers, an integer above JavaScript's safe-integer range and an extension), an empty capture, and a malformed negative control. Across 12 actual CLI calls: - Decoder 12.2.3 accepted the nonempty/empty files from both producers (four successes), reported its actual 12.2.3 identity, and rejected both malformed controls as `invalid_input`. - Decoder 12.3.1 refused all six calls with `unsupported_provider`; the concrete reason was `Expected mitmproxy 12.2.3; observed 12.3.1.` - Every source file's SHA-256 remained unchanged. An earlier slim-container run lacked `ps` and stopped at ownership preflight; that is retained as a harness prerequisite failure, not evidence of this version refusal. I plan to admit only the two actually verified profiles, retain 12.2.3 compatibility, report the running decoder's exact version, and keep unverified versions/foreign decoder identities rejected. The existing offline/no-server/resource/cleanup boundaries stay in place. Search hits' actual relevant changes (#2876 headline indexing and #4924 HTTP/3 reset verification) do not update this version gate; I have not run foreign PR heads. This does not verify the advisory claims in the issue, live TLS/HTTP3 capture, other mitmproxy versions, or other hosts. No product implementation has been made yet; original CLI outputs, tool archive hashes and immutable fixture hashes are retained. Update: a publication-time recheck found #8088 by gyanu2507 (created 2026-10-30T03:02:45Z, before this comment). My initial search did not capture it. I read its actual production diff at head `325266aabb68e5b77bd79f7ad892df2621a0c81e`: it changes the same native version gate/profile identity and SaveHar producer admission. My compatibility-set implementation is still an uncommitted local experiment and is now read-only HOLD; I will not submit a duplicate PR or package its legacy/HAR/test residuals as another contribution. The real 12.3.1 offline verifier completed 148 public cases locally, but there has been no independent Standards/Spec review, own source commit, fork push or upstream PR. I have not run #8088, and no source adoption or author credit is established. The earlier reproduction remains a record of main317, not an endorsement or runtime validation of the other PR. No issue close or reply to the other PR is being made.

bsakaguchi commented

2026-10-31 00:52:15 +00:00

Author

Owner

@bonro commented on GitHub (Oct 30, 2026):

We offer the full series of GPT models at 0.2x official pricing and the full series of Claude models at 0.3x official pricing, available now at lanmu1313.top.

@bonro commented on GitHub (Oct 30, 2026): We offer the full series of GPT models at 0.2x official pricing and the full series of Claude models at 0.3x official pricing, available now at lanmu1313.top.

bsakaguchi referenced this issue

2026-10-31 01:13:48 +00:00

[PR #4668] [MERGED] fix(electron): retain fuse descriptor ownership through failed final close #6351

bsakaguchi referenced this issue

2026-11-01 21:42:56 +00:00

[PR #5119] [CLOSED] fix(cli): clamp exhausted failure token-window start to the token total #6770