Skip to content

qprobe: refuse a URL as a URL, not as a CIDR block - #51

Merged
leonacostaok merged 1 commit into
mainfrom
fix/qprobe-url-target
Aug 7, 2026
Merged

qprobe: refuse a URL as a URL, not as a CIDR block#51
leonacostaok merged 1 commit into
mainfrom
fix/qprobe-url-target

Conversation

@leonacostaok

Copy link
Copy Markdown
Contributor

A probe run on a tracked repo failed with:

qprobe: refusing CIDR block "https://leonacosta.com" — qProbe probes one host at a time, not ranges.

The raw.includes("/") check ran before anything else, so every URL was reported as a range sweep. The message described a mistake the operator had not made and gave no hint about the fix. That cost a real run.

What changes

URLs are still refused — a target is one named host — but for the right reason, and the message names the host to use:

refusing URL "https://example.com/health" — qProbe takes a host, not a URL. Try: example.com
  • A slash is reported as a CIDR block only when it is actually a prefix length (10.0.0.0/24). A pasted path (example.com/blog) says path instead.
  • A target carrying credentials (mine.com@theirs.com) is refused explicitly, and the suggestion names the host it would really have connected to. --i-own-this is an ownership attestation, so a target that reads as one host and resolves to another must not be accepted quietly — and if you are going to refuse it, showing which host it actually resolves to is the useful part.

What does not change

The suggestion is for the message only. Nothing is newly accepted. The refusals that are security controls — CIDR blocks, IP ranges, wildcards, lists — still throw before any network I/O, and there is a test asserting the CIDR path still reports as CIDR so this cannot be loosened by accident.

I deliberately did not make qProbe accept URLs and normalise them internally. parseTarget's stated stance is that the refusal is a security control rather than a convenience check, and silently resolving https://mine.com@theirs.com/ to theirs.com would widen what --i-own-this attests to. The website generating the workflow normalises instead, where the resolved host is visible in the committed file.

SemVer: patch. Message and classification only.

Verified

npm run build, npm run lint, npm run format:check, npm test across all 8 packages, 0 failures. qprobe's own suite goes 49 → 55 tests: URL-not-CIDR with the suggested host, path vs real CIDR, credentials, non-https schemes, and the plain forms still parsing.

Also documents in --help and the README that a target is a host, not a URL, since the interface never actually said so.

Related

quantakrypto/website#118 strips the scheme when generating the probe workflow, so the bad target cannot be produced from the dashboard in the first place. This is the other half: the tool explaining itself correctly when someone types one by hand.

`qprobe --i-own-this https://example.com` failed with

  refusing CIDR block "https://example.com" - qProbe probes one host at a time,
  not ranges.

The slash check ran before anything else, so every URL was reported as a range
sweep: an error describing a mistake the operator had not made, and one that
gave no hint about the fix. It cost a real probe run on a tracked repo.

URLs are still refused, because a target is one named host, but now for the
right reason and with the host to use:

  refusing URL "https://example.com/health" - qProbe takes a host, not a URL.
  Try: example.com

A slash is only reported as a CIDR block when it is actually a prefix length
(10.0.0.0/24); a pasted path says so instead. A target carrying credentials is
refused explicitly, and the suggestion names the host it would really have
connected to - --i-own-this is an ownership attestation, so a target that reads
as one host and resolves to another must not be accepted quietly.

The suggestion is for the message only. Nothing is newly accepted: the refusals
that are security controls (CIDR, ranges, wildcards, lists) still throw before
any network I/O.
@leonacostaok
leonacostaok merged commit 6a09d2d into main Aug 7, 2026
14 checks passed
@leonacostaok
leonacostaok deleted the fix/qprobe-url-target branch August 7, 2026 09:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant