tfks/dropbear
tfks/dropbear
4
0
Fork 0
Code Issues 5 Pull requests Projects Releases 3 Packages Wiki Activity Actions

Inherit remote-* register defaults from an existing root.toml #17

Merged
erik merged 3 commits from chore/register-remote-defaults into main 2026-06-26 23:31:55 +00:00
Conversation 0 Commits 3 Files changed 5 +237 -26
agent-dev commented 2026-06-26 20:56:48 +00:00
Member
Copy link

Refs: #14

What

Registering a device into a directory that already contains .dropbear/root.toml now inherits that file's [remote] table as defaults for the register --remote-* flags. This makes sharing a sync root across devices simpler: copy the root.toml, then register --root-id … --device-id … without re-typing bucket/endpoint/region/prefix.

  • loadRemoteDefaults reads and parses the existing root.toml (best-effort; nil when absent or unparseable — genuine corruption is still surfaced later by config.Init).
  • registerExecute seeds the remote map from those defaults, then applies any explicitly-set --remote-* flags on top as overrides.
  • --remote-bucket / --remote-endpoint are now required only when neither a flag nor the existing root.toml provides them; their help text notes the fallback.
  • New test TestRegisterInheritsRemoteDefaultsFromExistingRootTOML asserts the inherited bucket/endpoint/region/prefix reach the object-store config.

Validation

just validate gates format, vet, lint, units, secrets — all pass. The final test::audit (govulncheck) gate reports 3 Go standard-library vulnerabilities (GO-2026-5036/5037/5038, fixed in go1.26.4; local toolchain is go1.26.3) in unrelated files (deviceregistry, objectstore, statusapi). This failure reproduces identically on a clean origin/main and is unrelated to this change, which adds no dependencies and causes no go.mod/go.sum drift. Out of scope to fix here (toolchain bump).

Refs: #14 --- ## What Registering a device into a directory that already contains `.dropbear/root.toml` now inherits that file's `[remote]` table as defaults for the `register --remote-*` flags. This makes sharing a sync root across devices simpler: copy the root.toml, then `register --root-id … --device-id …` without re-typing bucket/endpoint/region/prefix. - `loadRemoteDefaults` reads and parses the existing root.toml (best-effort; nil when absent or unparseable — genuine corruption is still surfaced later by `config.Init`). - `registerExecute` seeds the remote map from those defaults, then applies any explicitly-set `--remote-*` flags on top as overrides. - `--remote-bucket` / `--remote-endpoint` are now required only when neither a flag nor the existing root.toml provides them; their help text notes the fallback. - New test `TestRegisterInheritsRemoteDefaultsFromExistingRootTOML` asserts the inherited bucket/endpoint/region/prefix reach the object-store config. ## Validation `just validate` gates format, vet, lint, units, secrets — all pass. The final `test::audit` (govulncheck) gate reports 3 Go **standard-library** vulnerabilities (GO-2026-5036/5037/5038, fixed in go1.26.4; local toolchain is go1.26.3) in unrelated files (`deviceregistry`, `objectstore`, `statusapi`). This failure reproduces identically on a clean `origin/main` and is unrelated to this change, which adds no dependencies and causes no go.mod/go.sum drift. Out of scope to fix here (toolchain bump).
Inherit remote-* register defaults from an existing root.toml
All checks were successful
Validate / validate (pull_request) Successful in 46s
Details
fd21e93c43 
When the target directory already holds a .dropbear/root.toml — for example one copied from a peer device to share a sync root — register now reads its [remote] table and uses those values as defaults for the --remote-* flags. Explicit flags still override, and --remote-bucket / --remote-endpoint are only required when neither a flag nor the existing root.toml supplies them.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Register a new device against an existing root without --force
All checks were successful
Validate / validate (pull_request) Successful in 49s
Details
45d9860c7c 
Copying a root.toml to a new host and running register under a different device_id is a legitimate new-device registration, not a clobber. config.Init now overwrites a matching-root_id root.toml when the requested device_id differs from the on-disk one; re-registering the same device_id still requires --force as the accidental-re-init guard. The remote side already supports this (EnsureRootNotInitialized passes once a device registry exists, and Register appends the new device).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Inherit mode from an existing root.toml on register
All checks were successful
Validate / validate (pull_request) Successful in 48s
Details
eeff880710 
register already seeds the --remote-* flags from an existing .dropbear/root.toml via loadRemoteDefaults, but mode was not inherited — it fell back to the flag default bidirectional. A device that omitted --mode against a shared upload-only root silently downgraded it to bidirectional.

Make --mode default to empty and resolve it the same way the [remote] defaults are: an explicit flag wins, otherwise inherit mode from the on-disk root.toml, otherwise fall back to bidirectional. Add a test pinning both the inheritance and the explicit-override paths.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
erik merged commit 06a8ca254a into main 2026-06-26 23:31:55 +00:00
erik deleted branch chore/register-remote-defaults 2026-06-26 23:31:55 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
  
agent
blocked
 Needs human intervention

  
agent
new
 Waiting triage by PM

  
agent
review
 Awaiting next phase

  
agent
working
 Agent is actively implementing

  
complexity
high
 High complexity - use more capable LLM

  
complexity
low
 Low complexity - use simpler LLM

  
priority
high
 High priority

  
priority
low
 Low priority

  
priority
medium
 Medium priority

  
risk
high
 High risk — strict QA, no auto-release

  
risk
low
 Low risk — standard flow

  
risk
medium
 Medium risk — standard QA

  
type
bug
 Bug fix

  
type
chore
 Maintenance, deps, tooling

  
type
feature
 New feature — spec required

  
type
security
 Security change — spec + strict QA required

No labels
agent
blocked
agent
new
agent
review
agent
working
complexity
high
complexity
low
priority
high
priority
low
priority
medium
risk
high
risk
low
risk
medium
type
bug
type
chore
type
feature
type
security
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
erik
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
tfks/dropbear!17
No description provided.