tak:// cert cache: residual gaps after #100 / v7.3.13 #101

#100 (merged, v7.3.13) fixed the headline stale-cert bug by probing the live server certificate and invalidating the cache when the fingerprint changes. Three residual gaps survived into the release:

1. Legacy cache entries never get a fingerprint sidecar, so pre-7.3.13 victims stay stuck. The .server sidecar is only written on fresh enrollment. A user upgrading from <=7.3.12 with a stale-but-time-valid cached cert takes the legacy fallback, has no cached fingerprint (cached_server_fp empty -> server_cert_changed False), gets a cache hit, and keeps failing the TLS handshake — exactly the population the fix targets. Suggest: write the sidecar on any successful cache-hit connection, or treat missing sidecar + fingerprint readable as stale, or purge the cache entry on TLS handshake failure.

2. Port in the cache key causes redundant enrollments. Enrollment always talks to the Marti port (8446) regardless of the tak:// URL port, and issues one client credential per user per server. Keying the cache on hostname:port:username means the same user connecting on 8089 and 8443 enrolls twice — double the issued certs server-side, double the private-key material on disk, no correctness benefit now that CA change is detected by fingerprint.

3. Passphrase written before permissions are restricted. open(new_pass_path, 'w') followed by os.chmod(..., 0o600) leaves a umask-dependent window where the p12 passphrase is world-readable. Use os.open(path, os.O_WRONLY|os.O_CREAT|os.O_TRUNC, 0o600).

Nit: the cache key joins hostname:port:username with unescaped colons; parse_tak_url can yield hostnames containing :, so distinct tuples can theoretically collide (length-prefix or use a non-URL delimiter). Relatedly, bare IPv6 literals mis-parse in parse_tak_url (host=::1 -> hostname :, port 1).

🤖 Generated with Claude Code

https://claude.ai/code/session_01DVibvSyvPsUXRXRYaFsWjY