secure-storage uses mock keyring on macOS because apple-native is not enabled

[alexbonea]

Summary

On macOS, a v0.3.27 build with --features secure-storage does not use the native Keychain backend. The keyring dependency is enabled without its apple-native feature, and keyring 3.x intentionally falls back to the in-memory mock store when no platform credential-store feature applies.

Current wiring

keyring = { version = "3", optional = true }

[features]
secure-storage = ["keyring"]

The resolved feature graph contains only keyring feature "default"; it does not contain keyring feature "apple-native".

Symptom

linear-cli auth oauth --secure completes the OAuth exchange and then fails during immediate readback with the message about locally built or unsigned binaries. Because the mock backend creates a fresh empty credential for the read, the written OAuth payload is not persisted. The code-signing message is therefore misleading for this case.

Verified macOS fix

keyring = { version = "3", optional = true, features = ["apple-native"] }

After regenerating the lockfile and rebuilding v0.3.27 with this change:

• cargo tree --features secure-storage -e features -i keyring shows keyring feature "apple-native";
• the binary links Security.framework and CoreFoundation.framework;
• auth oauth --secure completes successfully;
• auth status --validate reports OAuth configured, keyring configured, and validated.

Tested on macOS arm64. No plaintext credential fallback was used.

Cross-platform note

The README advertises Keychain, Credential Manager, and Secret Service support. Since keyring 3.x has no default platform-store features, Windows and Linux likely also need explicit native feature wiring. The upstream fix may therefore be better expressed as the intended cross-platform feature matrix rather than only the macOS one-line change.

[Finesssee]

Thanks for the report, I will try to fix this ASAP.