mirror of https://github.com/wweir/sower.git synced 2026-10-20 00:15:34 +00:00

Files

T

wweir 0b27a34f3e fix(install): generate the client password instead of the placeholder

`sowerd -i` wrote config.ExampleSowerdConfigTOML verbatim, so a fresh
install started with `password = "change_me"` — a publicly known credential
— while Validate rejects only an empty password. The admin console already
generates a random password when none is configured; do the same here.

- renderDefaultConfig replaces the template's top-level `password = ` line
  with a random 128-bit hex value (the commented `# password = ...` sample
  inside site_routes.auth is left alone) and errors when the template has no
  such line, instead of silently keeping a known value.
- The password is printed once during install for the client configs, and an
  existing /etc/sower/sowerd.toml is still never rewritten.
- docs: security.md states this under "What the Transport Password Gates"
  and moves the risk out of Residual Accepted Signals — a fixable
  operational defect is not an inherent signal — recording the declined
  alternative (a placeholder blocklist in Validate) with its rationale;
  ARCHITECTURE/README describe the generated password.

Gate: gofmt, go vet ./..., go test ./... green; install_e2e_test PASS.

2026-10-12 10:44:47 +08:00

plans

docs(plans): correct the fake-site fallback claim in the site routing plan

2026-10-10 14:57:03 +08:00

README.md

docs: security model for the sowerd edge; document the unknown-SNI cert fallback

2026-09-18 18:05:02 +08:00

security.md

fix(install): generate the client password instead of the placeholder

2026-10-12 10:44:47 +08:00

README.md

Documentation Index

This directory contains long-lived design documents. Per AGENTS.md rules:

docs/ root holds only finalized, authoritative design documents (product, architecture, protocol, security, deployment, data model, test strategy, etc.).
docs/plans/ holds draft proposals and in-progress implementation plans — not authoritative.
docs/reviews/ holds review records, issue lists, and retrospective summaries — not authoritative.

When a plan or review produces a durable rule, it must be written back to the relevant root-level design document and referenced from this index.

Cross-document references must point to root-level design documents only. Never reference protocol, field, security, or deployment rules from plans/ or reviews/.

Root-Level Documents

Document	Description
ARCHITECTURE.md	System boundary, layer responsibilities, data flows, design decisions
security.md	sowerd edge threat model, anti-probing layers, unknown-SNI certificate fallback, rejected directions

Plans

Historical plans live under docs/plans/ and are not authoritative. Durable rules from completed plans are reflected only in the root-level documents listed above.

Reviews

No reviews yet.