allow_private=True also switches off the IANA special-use blocklist #1357

adcp.signing.validate_resolved_ip puts its entire blocked set behind one
boolean. allow_private=True is documented as "skip the reserved-range check.
For tests only" — a caller enables it to dial a test's own loopback origin or a
container-bridge address. It also admits every IANA special-use range the
validator knows, including the ranges PR #974 added for exactly the opposite
reason.

What the flag relaxes

Measured against adcp 8.0.0 on CPython 3.14.6, one address per range:

The first six rows are what the flag's name and docstring describe. The 23 bold
rows are not private address space. 100.64.0.0/10 is the range AdCP 3.1.1
names in the deny list a fetcher MUST apply ("Webhook URL validation (SSRF)",
step 2), and the module's own comment records why it is there: "routable inside
carrier and container networks (and is where Alibaba's metadata endpoint
lives), so leaving it open is a real SSRF path into an operator's internal
network." allow_private=True leaves it open.

The bold rows also show why a flag-level relaxation cannot be narrow.
ipaddress.is_private is a far wider predicate than RFC 1918: it reports True
for RFC 5737 and RFC 3849 documentation space, RFC 2544 benchmarking, RFC 6890
protocol assignments, 6to4, Teredo, RFC 6666 discard-only and 240.0.0.0/4.
None of that is private address space, and relaxing the flag relaxes all of it.

Runnable

import ipaddress
from adcp.signing import validate_resolved_ip
from adcp.signing.jwks import SSRFValidationError

for addr in ("100.64.0.1", "192.88.99.1", "2001:20::1", "169.254.1.1", "224.0.0.1"):
    ip = ipaddress.ip_address(addr)
    for allow_private in (False, True):
        try:
            validate_resolved_ip(ip, allow_private=allow_private)
            verdict = "ACCEPT"
        except SSRFValidationError:
            verdict = "REFUSE"
        print(f"{addr:16} allow_private={allow_private!s:5} -> {verdict}")

Output on adcp 8.0.0:

100.64.0.1       allow_private=False -> REFUSE
100.64.0.1       allow_private=True  -> ACCEPT
192.88.99.1      allow_private=False -> REFUSE
192.88.99.1      allow_private=True  -> ACCEPT
2001:20::1       allow_private=False -> REFUSE
2001:20::1       allow_private=True  -> ACCEPT
169.254.1.1      allow_private=False -> REFUSE
169.254.1.1      allow_private=True  -> ACCEPT
224.0.0.1        allow_private=False -> REFUSE
224.0.0.1        allow_private=True  -> ACCEPT

Layer: API DESIGN

One hand-authored signature choice. The ranges are correct, the predicate is
correct, the list PR #974 added is complete. The flag's scope is drawn across
two concerns instead of one.

Downstream consequence

A caller has no way to ask for the thing the flag is named for. The two range
tables (_EXTRA_BLOCKED_NETWORKS, BLOCKED_METADATA_IPS) are module-private
and absent from adcp.signing.__all__, and the only knob is the boolean:

>>> import adcp.signing as S
>>> [n for n in S.__all__ if "BLOCK" in n.upper() or "NETWORK" in n.upper()]
[]
>>> hasattr(S, "_EXTRA_BLOCKED_NETWORKS")
False

An adopter that wants loopback for its test origins and the special-use
blocklist for its buyer-supplied webhook URLs re-enumerates the ranges in its
own code and applies them outside the SDK call. Where the dialled URL is
publisher- or buyer-supplied — jwks_uri, authoritative_location,
pushNotificationConfig.url — that is the posture the SDK should be providing.

Fix

Split the blocked set at the reachability line and give each half its own gate:
allow_private for RFC 1918, RFC 4193 and loopback; allow_special_use for
the rest. Cloud metadata IPs stay blocked under both. PR to follow.

Related

One instance of a pattern in src/adcp/signing/: a rule declared in one place
and decided in another. #1354 enumerates the others.