Eclipse Secure Storage ↔ OS Credential Store: Least‑Privilege and Expired Credential Handling

The goal is to understand how Eclipse’s Secure Storage interacts with the host operating system’s credential store to enforce least‑privilege access and manage expired authentication tokens across Windows, macOS, and Linux. Eclipse stores sensitive data encrypted with a master password, optionally delegating encryption to OS keychains, but the runtime permissions model allows any bundle with the Secure Storage API to read entries it is authorized for. A key uncertainty is whether Eclipse automatically prompts for a master password when a credential store provider changes (e.g., moving from a local file to the OS keychain) and how expired tokens are detected and refreshed without explicit plugin intervention.

Specific questions:

• Does Eclipse automatically prompt for a master password when migrating to a different OS credential provider?
• Can Eclipse detect expired credentials and prompt for a refresh without relying on plugin‑specific logic?
• What mechanisms exist to revoke or invalidate a credential stored in Secure Storage when the underlying OS token has expired?