You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(This has really been an issue I've worried over from the outset of the project; as I've started trying to implement a solution recently, as it kind of blocks #72, best to get it documented.)
CLI users would be able to perform a series of operations without passing (or being prompted for) a password if the app supported a 'session'. This would also simplify #72.
One way to implement this would be provide an interactive shell (so that credentials remain in memory between commands), but that would block support for desired things like piping between OS commands and phibes commands.
So phibes must be able to find something that enables interaction with the locker, meaning it has to be able to get/derive the encryption key. It should not be able to find that something on disk, which leaves environment variables.
The most direct approach would be via an environment variable holding the password. I've just generally got misgivings about this. I'd be less wary of there were an automatic method for expiring environment variables (especially on all supported platforms), but there isn't, AFAIK. (Having, instead, the password hash would at least have it obfuscated, but the encryption key is, by design, not derivable from the password hash. And I'm even more uncomfortable having the encryption key exposed.)
Summarizing:
The CLI needs to be able to derive the encryption key for the target user locker.
That capability must depend on something found in the ephemeral environment (not on disk).
The text was updated successfully, but these errors were encountered:
(This has really been an issue I've worried over from the outset of the project; as I've started trying to implement a solution recently, as it kind of blocks #72, best to get it documented.)
CLI users would be able to perform a series of operations without passing (or being prompted for) a password if the app supported a 'session'. This would also simplify #72.
One way to implement this would be provide an interactive shell (so that credentials remain in memory between commands), but that would block support for desired things like piping between OS commands and phibes commands.
So phibes must be able to find something that enables interaction with the locker, meaning it has to be able to get/derive the encryption key. It should not be able to find that something on disk, which leaves environment variables.
The most direct approach would be via an environment variable holding the password. I've just generally got misgivings about this. I'd be less wary of there were an automatic method for expiring environment variables (especially on all supported platforms), but there isn't, AFAIK. (Having, instead, the password hash would at least have it obfuscated, but the encryption key is, by design, not derivable from the password hash. And I'm even more uncomfortable having the encryption key exposed.)
Summarizing:
The text was updated successfully, but these errors were encountered: