[client] Let a logged-out profile deserialize again (review item 2)

ConfigFromJSON refused a document with no WireGuard or SSH key. A config
legitimately has none between a logout and the next login: mobile
LogoutProfile clears both in place and writes the profile back, so the peer
re-registers on the next login instead of returning as itself.

So the refusal broke the mobile flows it was meant to protect. On iOS and
tvOS the stored JSON of a logged-out profile stopped loading through
Client.SetConfigFromJSON and Auth.SetConfigFromJSON, and copyConfig — which
round-trips a Config through JSON to take an in-memory copy before applying
the MDM overlay — failed on the same document. Where the old code silently
minted a key, this returned an error, which is worse for logout and profile
switching alike: neither is asking to connect.

The deserializer now stays out of the identity question in both directions:
it does not generate one (a read cannot hand back keys nothing will write
down) and does not refuse one that is absent. Whoever goes on to connect is
where an absent identity has to be answered — and it already is, by the
login path that provisions and persists.

ErrConfigWithoutIdentity goes with it; nothing else used it.
This commit is contained in:
riccardom
2026-09-11 14:53:04 +02:00
parent 222ad91c4d
commit 07dc9cb1c8
4 changed files with 32 additions and 52 deletions
+8 -17
View File
@@ -1443,17 +1443,15 @@ func ConfigToJSON(config *Config) (string, error) {
// ConfigFromJSON deserializes a JSON string to a Config struct.
// This is useful for restoring config from alternative storage mechanisms.
// After unmarshaling, defaults are applied to ensure the config is fully
// initialized. The peer identity is not one of those defaults: a document
// carrying none is refused with ErrConfigWithoutIdentity.
// initialized.
//
// Provisioning one here would be worse than refusing. Both callers connect
// with what they get back — the iOS SDK's Client.SetConfigFromJSON keeps it as
// the preloaded config Run() uses, and Auth.SetConfigFromJSON as the config it
// authenticates with — and neither can hand a generated key back to the store
// the document came from, since Client exports no config at all. The peer
// would connect under an identity nothing persists and re-register on every
// launch. A document with no identity means nobody has logged in yet, and
// that is what the caller has to be told.
// The peer identity is deliberately none of its business, in either direction.
// It does not generate one: a read cannot hand back keys that nothing will
// write down (see ReadOrGenerateConfig). Nor does it refuse a document that
// carries none, because a config legitimately has no identity between a logout
// and the next login — mobile logout clears both keys in place — and this is
// also the deserializer the iOS SDK copies a config through. Whoever goes on
// to connect is where an absent identity has to be answered.
func ConfigFromJSON(jsonStr string) (*Config, error) {
config := &Config{}
err := json.Unmarshal([]byte(jsonStr), config)
@@ -1467,12 +1465,5 @@ func ConfigFromJSON(jsonStr string) (*Config, error) {
return nil, fmt.Errorf("failed to apply defaults to config: %w", err)
}
// Both keys, because both are dead ends when missing: an empty WireGuard
// key fails the management login on its size, and an empty SSH key fails
// ssh.GeneratePublicKey in ConnectClient before the engine starts.
if config.PrivateKey == "" || config.SSHKey == "" {
return nil, ErrConfigWithoutIdentity
}
return config, nil
}