The fetcher matches an IPv4-mapped address (::ffff:a.b.c.d) as the IPv4 address it holds, so a blocked_networks entry written in that form loaded without complaint and refused nothing. pixa now keeps such an entry as the IPv4 range it covers, so ::ffff:10.0.0.0/104 becomes 10.0.0.0/8. An entry in that form shorter than /96 covers more than IPv4 addresses and has no IPv4 range to become; it aborts startup with an error naming blocked_networks and the value. Matching in internal/httpfetcher is unchanged. README.md says both under blocked_networks.
The first commit adds two new tests and fails; the second makes them pass.
Worth knowing:
::ffff:0:0/96 becomes 0.0.0.0/0 and refuses every IPv4 address, which is what that entry covers.
The error shows the entry as Go prints it: ::ffff:a00:0/80 is reported as ::ffff:10.0.0.0/80.
Disclosures:
Judgement call: the change is a new parseBlockedNetworks that calls parseCIDRList, not a change inside it, because trusted_proxies uses the same parser and the issue covers blocked_networks only.
Not fixed here: a trusted_proxies entry in the IPv4-mapped form has the same fault, since the client address is also matched as IPv4. Filed as #303.
Model: opus-5-5
Implements https://git.eeqj.de/sneak/pixa/issues/301.
The fetcher matches an IPv4-mapped address (`::ffff:a.b.c.d`) as the IPv4 address it holds, so a `blocked_networks` entry written in that form loaded without complaint and refused nothing. pixa now keeps such an entry as the IPv4 range it covers, so `::ffff:10.0.0.0/104` becomes `10.0.0.0/8`. An entry in that form shorter than `/96` covers more than IPv4 addresses and has no IPv4 range to become; it aborts startup with an error naming `blocked_networks` and the value. Matching in `internal/httpfetcher` is unchanged. `README.md` says both under `blocked_networks`.
The first commit adds two new tests and fails; the second makes them pass.
Worth knowing:
- `::ffff:0:0/96` becomes `0.0.0.0/0` and refuses every IPv4 address, which is what that entry covers.
- The error shows the entry as Go prints it: `::ffff:a00:0/80` is reported as `::ffff:10.0.0.0/80`.
Disclosures:
- Judgement call: the change is a new `parseBlockedNetworks` that calls `parseCIDRList`, not a change inside it, because `trusted_proxies` uses the same parser and the issue covers `blocked_networks` only.
- Not fixed here: a `trusted_proxies` entry in the IPv4-mapped form has the same fault, since the client address is also matched as IPv4. Filed as https://git.eeqj.de/sneak/pixa/issues/303.
Model: opus-5-5
internal/config/blocked_networks_internal_test.go, the two new tests: nothing pins the /96 limit. They try only /104, which loads, and /80, which is refused. So they would still pass if parseBlockedNetworks refused /96 to /103, such as ::ffff:0:0/96, which should load as 0.0.0.0/0. They would also pass if it accepted /81 to /95 and loaded each as a range that refuses nothing, the fault this issue fixes. Acceptable: a case on each side of the limit in the new tests, for instance ::ffff:0:0/96 loads as 0.0.0.0/0 and ::ffff:0:0/95 aborts startup naming blocked_networks. Both fail on next, as test first requires.
Disclosures:
Judgement call: putting the conversion in its own function beside parseCIDRList is accepted as the plainest shape that leaves trusted_proxies unchanged. #303 can move it into parseCIDRList once both settings need it.
Judgement call: the refusal quotes the entry as Go prints it, so ::ffff:0:0/80 is reported as ::ffff:0.0.0.0/80. The other blocked_networks errors quote the entry as written. Not counted, since it still names the setting and the entry.
Judgement call: the blocked_networks comment in configs/config.example.yml does not mention the new refusal. Not counted, since the issue names README.md as the place to document it.
Model: opus-5-5
Review failed: needs-rework.
1. `internal/config/blocked_networks_internal_test.go`, the two new tests: nothing pins the `/96` limit. They try only `/104`, which loads, and `/80`, which is refused. So they would still pass if `parseBlockedNetworks` refused `/96` to `/103`, such as `::ffff:0:0/96`, which should load as `0.0.0.0/0`. They would also pass if it accepted `/81` to `/95` and loaded each as a range that refuses nothing, the fault this issue fixes. Acceptable: a case on each side of the limit in the new tests, for instance `::ffff:0:0/96` loads as `0.0.0.0/0` and `::ffff:0:0/95` aborts startup naming `blocked_networks`. Both fail on `next`, as test first requires.
Disclosures:
- Judgement call: putting the conversion in its own function beside `parseCIDRList` is accepted as the plainest shape that leaves `trusted_proxies` unchanged. https://git.eeqj.de/sneak/pixa/issues/303 can move it into `parseCIDRList` once both settings need it.
- Judgement call: the refusal quotes the entry as Go prints it, so `::ffff:0:0/80` is reported as `::ffff:0.0.0.0/80`. The other `blocked_networks` errors quote the entry as written. Not counted, since it still names the setting and the entry.
- Judgement call: the `blocked_networks` comment in `configs/config.example.yml` does not mention the new refusal. Not counted, since the issue names `README.md` as the place to document it.
Model: opus-5-5
Two new tests, failing until the fix. Entries such as
::ffff:10.0.0.0/104 and ::ffff:0:0/96 must load as 10.0.0.0/8 and
0.0.0.0/0, since the fetcher matches an IPv4-mapped address as the IPv4
address it holds. An entry in that form shorter than /96, such as
::ffff:0:0/95, must abort startup naming blocked_networks.
Model: opus-5-5
The fetcher matches an IPv4-mapped address (::ffff:a.b.c.d) as the
IPv4 address it holds, so a blocked_networks entry written in that form
was accepted and matched nothing. Such an entry is now kept as the IPv4
range it covers: ::ffff:10.0.0.0/104 becomes 10.0.0.0/8. One shorter
than /96 covers more than IPv4 addresses and aborts startup naming the
setting. trusted_proxies shares the list parser and is unchanged.
README.md says both.
Model: opus-5-5
The test commit now also checks that ::ffff:0:0/96 loads as 0.0.0.0/0 and that ::ffff:0:0/95 aborts startup naming blocked_networks; both fail without the fix. The fix commit is unchanged, and the branch is rebased on next.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/pixa/pulls/302#issuecomment-146516:
1. The test commit now also checks that `::ffff:0:0/96` loads as `0.0.0.0/0` and that `::ffff:0:0/95` aborts startup naming `blocked_networks`; both fail without the fix. The fix commit is unchanged, and the branch is rebased on `next`.
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.
Implements #301.
The fetcher matches an IPv4-mapped address (
::ffff:a.b.c.d) as the IPv4 address it holds, so ablocked_networksentry written in that form loaded without complaint and refused nothing. pixa now keeps such an entry as the IPv4 range it covers, so::ffff:10.0.0.0/104becomes10.0.0.0/8. An entry in that form shorter than/96covers more than IPv4 addresses and has no IPv4 range to become; it aborts startup with an error namingblocked_networksand the value. Matching ininternal/httpfetcheris unchanged.README.mdsays both underblocked_networks.The first commit adds two new tests and fails; the second makes them pass.
Worth knowing:
::ffff:0:0/96becomes0.0.0.0/0and refuses every IPv4 address, which is what that entry covers.::ffff:a00:0/80is reported as::ffff:10.0.0.0/80.Disclosures:
parseBlockedNetworksthat callsparseCIDRList, not a change inside it, becausetrusted_proxiesuses the same parser and the issue coversblocked_networksonly.trusted_proxiesentry in the IPv4-mapped form has the same fault, since the client address is also matched as IPv4. Filed as #303.Model: opus-5-5
Review failed: needs-rework.
internal/config/blocked_networks_internal_test.go, the two new tests: nothing pins the/96limit. They try only/104, which loads, and/80, which is refused. So they would still pass ifparseBlockedNetworksrefused/96to/103, such as::ffff:0:0/96, which should load as0.0.0.0/0. They would also pass if it accepted/81to/95and loaded each as a range that refuses nothing, the fault this issue fixes. Acceptable: a case on each side of the limit in the new tests, for instance::ffff:0:0/96loads as0.0.0.0/0and::ffff:0:0/95aborts startup namingblocked_networks. Both fail onnext, as test first requires.Disclosures:
parseCIDRListis accepted as the plainest shape that leavestrusted_proxiesunchanged. #303 can move it intoparseCIDRListonce both settings need it.::ffff:0:0/80is reported as::ffff:0.0.0.0/80. The otherblocked_networkserrors quote the entry as written. Not counted, since it still names the setting and the entry.blocked_networkscomment inconfigs/config.example.ymldoes not mention the new refusal. Not counted, since the issue namesREADME.mdas the place to document it.Model: opus-5-5
818beae12cto11a6f5a60aRework for #302 (comment):
::ffff:0:0/96loads as0.0.0.0/0and that::ffff:0:0/95aborts startup namingblocked_networks; both fail without the fix. The fix commit is unchanged, and the branch is rebased onnext.Model: opus-5-5
Review passed.
Model: opus-5-5