pit: let an ending be all digits - #147
Merged
Merged
Conversation
`.420`, `.187`, `.911` could not be claimed. normalizeTld refused any all-numeric ending as "ambiguous against an IPv4 literal", which is true of a hostname and not of an ending: nothing reads `.420` on its own as an address. The ambiguity is real but belongs one level up. Several parsers read a two-part dotted number as an abbreviated IPv4 — `192.168` is `192.0.0.168` to some of them — so `1.420` genuinely cannot be told apart from an address while `blue.420` and `420.blue` obviously can. It takes both halves being numbers to create the collision. So the check moves to parseMoshpitName and applies to the whole name. An ending may be numeric, a label already could be, and only the pair is refused. In a pasted list the leading dot does the disambiguating: `.187` is an ending to point at, `187` on its own is a price. Both were already true; they just matter now that numeric endings exist. Three tests asserted the old rule and were rewritten rather than deleted — the IPv4 case they were protecting is still tested, at the level where it is actually a problem. 279 across the pwa suite. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
Merged
ralyodio
added a commit
that referenced
this pull request
Jul 31, 2026
* chore(release): v0.13.3 install.sh resolves releases/latest, so everything merged since v0.13.2 has been sitting on main unreachable — `moshcode dns enable` exists in the source and not in anyone's binary. The headline is the DNS bridge (#141). Moshpit names now resolve for every program on the machine, not just inside TronBrowser: each OS gets the mechanism that routes ONE SUFFIX rather than the one that replaces the resolver — /etc/resolver on macOS, systemd-resolved routing-only domains or dnsmasq on Linux, an NRPT rule per namespace on Windows. moshcode dns enable / disable / status moshcode uninstall <engine|tool> (#150, completion in #151) The pit gained most of a namespace registry in between: key pins per name (#137), pasted bulk claiming with per-line price and target (#138, #142, #143, #146), all-numeric endings (#147), /n/<name> serving a name or a directory (#145, #149), and Buy Now on an unclaimed name (#148). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore: restore the em-dash the version bump escaped The bump rewrote package.json through a JSON serialiser that defaults to ASCII, turning the em-dash in `description` into —. Valid JSON and the same string once parsed, but a gratuitous diff in a commit that should touch one line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
.420,.187,.911couldn't be claimed.normalizeTldrefused any all-numeric ending as "ambiguous against an IPv4 literal" — which is true of a hostname and not of an ending. Nothing reads.420on its own as an address.The ambiguity is real, just one level up
Several parsers read a two-part dotted number as an abbreviated IPv4 —
192.168is192.0.0.168to some of them. So1.420genuinely can't be told apart from an address, whileblue.420and420.blueobviously can. It takes both halves being numbers to create the collision.The check moved to
parseMoshpitNameand applies to the whole name:A label could already be numeric; now an ending can be too, and only the pair is refused.
In a pasted list
The leading dot disambiguates:
.187is an ending to point at,187on its own is a price. Both were already true — they just matter now that numeric endings exist.Tests
Three asserted the old rule and were rewritten, not deleted — the IPv4 case they were protecting is still tested, at the level where it's actually a problem.
279/279 pwa suite.
🤖 Generated with Claude Code