v0.19.1 — a refusal that says what to do about it

v0.19.0 refused an unsafe CA root correctly, and then left you standing there.

Both refusals printed the same line — "moshcode will not put an unconstrained root in your trust store" — with no next step. For one of them that sentence was not even true.

The two cases are nothing alike:

• stale — the root permits endings other than the ones claimed today, because it was generated when a different set was claimed. Nothing dangerous. Regenerating costs one command.
• dangerous — the root has no permitted DNS subtree, so it can vouch for any name on the internet.

Collapsing them into one dead end is how a safety gate gets worked around with --no-trust instead of satisfied: with no way to tell a real hole from an out-of-date file, the opt-out becomes the obvious move.

Each refusal now carries its own remedy, and only one of them has a way forward:

  STOP the root does not permit rank
       the root is older than the endings claimed now — regenerating it is enough:
         rm -rf ~/.moshpit/ca && moshpit-proxy   # writes a fresh root
       then re-run `moshcode dns enable`.

  STOP the root permits no DNS subtree, so every name it does not exclude is allowed
       moshcode will not put a root that can vouch for names outside Moshpit
       into your trust store. Names will resolve but not pass TLS until the
       root is regenerated with name constraints. This is not overridable.

The dangerous case is deliberately offered nothing, and a test asserts it never advertises --no-trust as the fix.

The rule itself is unchanged, and stays: one DNS:.com in a permitted subtree and the root reaches the clearnet. What was wrong was not the strictness — it was that being strict was a dead end.

Upgrading

moshcode update

1351 tests, 1348 pass, 0 fail, 3 skipped.