Flagged twice as out of scope during the reviews of #217, correctly — it is a gap in the DEFAULT BLOCKLIST, not in alwaysBlockedNetworks, and it predates that PR.
blockedNetworks in internal/delivery/ssrf.go covers private and IANA-reserved space. It does not cover provider service networks that live on PUBLIC unicast addresses. IBM Cloud is the concrete case: 161.26.0.0/16 and 166.8.0.0/14 are IBM-owned public ranges carrying in-cloud VPC DNS, NTP and package mirrors, reachable from a delivery target today with no allowlist set at all.
These are deliberately NOT candidates for alwaysBlockedNetworks, under the criterion that PR records above that variable: they are the operator's own in-cloud service network, and reaching operator infrastructure is the feature ALLOWED_EGRESS_CIDRS exists to provide. They also fail the "cannot collide with anything the operator runs" property that makes a host route free.
So the question this issue exists to answer is narrower and genuinely open: should the default blocklist refuse an operator's own in-cloud service network?
Arguments for: a webhook destination has no business resolving to your VPC's DNS resolver or package mirror, and an SSRF guard that stops at RFC1918 gives a false sense of coverage on any cloud that uses public space internally. Arguments against: these are not credential-vending, blocking them by default breaks a legitimate forward to a service the operator does run there, and the list is unbounded — every cloud has some version of this, so a partial list invites exactly the over-promising that has already been corrected twice on #217.
Also reported, and NOT accepted, in the same reviews: a GKE Services range 34.118.224.0/20. The prefix is unverified and it is a Kubernetes Service CIDR rather than a provider metadata network — do not add it without evidence.
Definition of done:
a decision recorded here on whether in-cloud provider service networks belong in the default blocklist
if yes: the entries added with each one's provider and purpose named, and the README stating plainly that the default blocklist now refuses some public addresses so an operator is not surprised
if no: the README says the default blocklist covers private and reserved space only, so nobody infers coverage it does not have
either way, the reasoning is recorded so a future sweep can refuse or accept candidates with a stated rule, as alwaysBlockedNetworks now does
Flagged twice as out of scope during the reviews of https://git.eeqj.de/sneak/webhooker/pulls/217, correctly — it is a gap in the DEFAULT BLOCKLIST, not in `alwaysBlockedNetworks`, and it predates that PR.
`blockedNetworks` in `internal/delivery/ssrf.go` covers private and IANA-reserved space. It does not cover provider service networks that live on PUBLIC unicast addresses. IBM Cloud is the concrete case: `161.26.0.0/16` and `166.8.0.0/14` are IBM-owned public ranges carrying in-cloud VPC DNS, NTP and package mirrors, reachable from a delivery target today with no allowlist set at all.
These are deliberately NOT candidates for `alwaysBlockedNetworks`, under the criterion that PR records above that variable: they are the operator's own in-cloud service network, and reaching operator infrastructure is the feature `ALLOWED_EGRESS_CIDRS` exists to provide. They also fail the "cannot collide with anything the operator runs" property that makes a host route free.
So the question this issue exists to answer is narrower and genuinely open: **should the default blocklist refuse an operator's own in-cloud service network?**
Arguments for: a webhook destination has no business resolving to your VPC's DNS resolver or package mirror, and an SSRF guard that stops at RFC1918 gives a false sense of coverage on any cloud that uses public space internally. Arguments against: these are not credential-vending, blocking them by default breaks a legitimate forward to a service the operator does run there, and the list is unbounded — every cloud has some version of this, so a partial list invites exactly the over-promising that has already been corrected twice on https://git.eeqj.de/sneak/webhooker/pulls/217.
Also reported, and NOT accepted, in the same reviews: a GKE Services range `34.118.224.0/20`. The prefix is unverified and it is a Kubernetes Service CIDR rather than a provider metadata network — do not add it without evidence.
Definition of done:
- a decision recorded here on whether in-cloud provider service networks belong in the default blocklist
- if yes: the entries added with each one's provider and purpose named, and the README stating plainly that the default blocklist now refuses some public addresses so an operator is not surprised
- if no: the README says the default blocklist covers private and reserved space only, so nobody infers coverage it does not have
- either way, the reasoning is recorded so a future sweep can refuse or accept candidates with a stated rule, as `alwaysBlockedNetworks` now does
Decision: no. The default blocklist does not take in-cloud provider service networks.
The rule, stated for future candidates: the default blocklist (blockedNetworks) covers private and IANA-reserved space, plus public addresses that serve cloud credentials (#245). An operator's own in-cloud service networks are not on it. They vend no credentials, reaching them can be legitimate, and every cloud has some, so a partial list would promise coverage it does not give. IBM Cloud's 161.26.0.0/16 and 166.8.0.0/14 are therefore not added, and neither is the unverified GKE range.
The README's egress section states the rule above in two or three sentences, so nobody infers wider coverage.
The comment above blockedNetworks in internal/delivery/ssrf.go states the same rule in one sentence, next to the existing rule for alwaysBlockedNetworks.
Docs and comment only; no list change.
Model: opus-5-5
Decision: no. The default blocklist does not take in-cloud provider service networks.
The rule, stated for future candidates: the default blocklist (`blockedNetworks`) covers private and IANA-reserved space, plus public addresses that serve cloud credentials (https://git.eeqj.de/sneak/webhooker/issues/245). An operator's own in-cloud service networks are not on it. They vend no credentials, reaching them can be legitimate, and every cloud has some, so a partial list would promise coverage it does not give. IBM Cloud's `161.26.0.0/16` and `166.8.0.0/14` are therefore not added, and neither is the unverified GKE range.
Work, after the fix for https://git.eeqj.de/sneak/webhooker/issues/245 lands:
- The README's egress section states the rule above in two or three sentences, so nobody infers wider coverage.
- The comment above `blockedNetworks` in `internal/delivery/ssrf.go` states the same rule in one sentence, next to the existing rule for `alwaysBlockedNetworks`.
- Docs and comment only; no list change.
Model: opus-5-5
clawbot
self-assigned this 2026-09-29 09:13:12 +02:00
Built in #339: the README's egress section and the comment above blockedNetworks now state that the default blocklist covers private and reserved space plus public addresses that serve cloud credentials, and nothing else. No list change.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/webhooker/pulls/339: the README's egress section and the comment above `blockedNetworks` now state that the default blocklist covers private and reserved space plus public addresses that serve cloud credentials, and nothing else. No list change.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Flagged twice as out of scope during the reviews of #217, correctly — it is a gap in the DEFAULT BLOCKLIST, not in
alwaysBlockedNetworks, and it predates that PR.blockedNetworksininternal/delivery/ssrf.gocovers private and IANA-reserved space. It does not cover provider service networks that live on PUBLIC unicast addresses. IBM Cloud is the concrete case:161.26.0.0/16and166.8.0.0/14are IBM-owned public ranges carrying in-cloud VPC DNS, NTP and package mirrors, reachable from a delivery target today with no allowlist set at all.These are deliberately NOT candidates for
alwaysBlockedNetworks, under the criterion that PR records above that variable: they are the operator's own in-cloud service network, and reaching operator infrastructure is the featureALLOWED_EGRESS_CIDRSexists to provide. They also fail the "cannot collide with anything the operator runs" property that makes a host route free.So the question this issue exists to answer is narrower and genuinely open: should the default blocklist refuse an operator's own in-cloud service network?
Arguments for: a webhook destination has no business resolving to your VPC's DNS resolver or package mirror, and an SSRF guard that stops at RFC1918 gives a false sense of coverage on any cloud that uses public space internally. Arguments against: these are not credential-vending, blocking them by default breaks a legitimate forward to a service the operator does run there, and the list is unbounded — every cloud has some version of this, so a partial list invites exactly the over-promising that has already been corrected twice on #217.
Also reported, and NOT accepted, in the same reviews: a GKE Services range
34.118.224.0/20. The prefix is unverified and it is a Kubernetes Service CIDR rather than a provider metadata network — do not add it without evidence.Definition of done:
alwaysBlockedNetworksnow doesDecision: no. The default blocklist does not take in-cloud provider service networks.
The rule, stated for future candidates: the default blocklist (
blockedNetworks) covers private and IANA-reserved space, plus public addresses that serve cloud credentials (#245). An operator's own in-cloud service networks are not on it. They vend no credentials, reaching them can be legitimate, and every cloud has some, so a partial list would promise coverage it does not give. IBM Cloud's161.26.0.0/16and166.8.0.0/14are therefore not added, and neither is the unverified GKE range.Work, after the fix for #245 lands:
blockedNetworksininternal/delivery/ssrf.gostates the same rule in one sentence, next to the existing rule foralwaysBlockedNetworks.Model: opus-5-5
Built in #339: the README's egress section and the comment above
blockedNetworksnow state that the default blocklist covers private and reserved space plus public addresses that serve cloud credentials, and nothing else. No list change.Model: opus-5-5