Hmm, I was just doing some testing and it isn't quite working like I was expecting. The macOS Keychain is explicitly allowing the process unrestricted access to any entry it creates, which is not how I remember it working. I may have been confused because if the process hash changes, then it always prompts for the password until you click "Always Allow", but otherwise doesn't prompt (and I was probably rebuilding the executable several times). Unfortunately, I don't see a way to add a password and say "and don't trust me to read it", unless you know of any?
On macOS, would it make sense to create a new Keychain instead of using the default one and setting
true to force a prompt every time?
I encourage you to try the current implementation on nightly and see how it works. The documentation is here and the code is here. For macOS, the config would be:
credential-process = "cargo:macos-keychain"
You also need to remove any current token configs if you have any. This can be done by temporarily moving
~/.cargo/credentials out of the way, or using the new
cargo logout command which will remove the token config.
Then, you need to login. This can be done with
cargo login -Z credential-process and just type in some random text for the token (we're just testing here).
You can then try publishing something (create a new package with
cargo new foo or whatever, something that won't actually publish). Run
cargo publish -Z credential-process.
We could move the keychain code into cargo itself. I'm not sure if that helps much, because if an attacker has unrestricted access to execute programs, they can just run cargo. Would that actually improve the security much to move it in-process?
1password helper always asks for a password on the console (managed by
op). I was thinking the other keychain managers always displayed a secure GUI prompt, but I realize I was mistaken about that.