Integration with "Keychain Access", more secure uses

[cw1nte]

Hi. First thanks for thought provoking and some fun. The Secrets file and secret (as a kind of entry, as seen by the UI) are a bit unclear to me. The ks script or the help could maybe clarify this a bit? Also that the secrets_file is per user (I always have atl east a priv and non-priv user, as I suspect would many people). So I was a priv shell to install with sudo but then testing as non priv user in the UI "Keychain Access" where nothing seemed to appear. I then chown the ks script for owner,staff and could use it as non priv shell. Created a new Secrets file for that user. Then UI "Keychain Access" (as non priv UI user) saw the Keychain.

So seemed better to enter secrets via "Keychain Access" - so the data is not in my command logging systems (I run a sqlite3 db of command date on top of the normal logging, that is my own so would at least let me trim and delete secrets.) BUT the "Keychain Access" UI only seems to allow me to create items where Kind="secure note" or "password item"... ks will list those $ ks ls test secNote_UI

but then cannot really see them $ ks show secNote_UI Secret "secNote_UI" was not found in keychain.

Is there some way to unify the 2 areas/tools? [I am using El Capitan 10.11.6 as my tech and dev world since I like my greater freedom there. Not yet tried this on Catalina, say]

[cw1nte]

PS the uppercase Secrets for keychain file and lowercase "secret" for Kind similarity/differences are a bit confusing, if I did not maybe make that point clear above. User only expects one thing "Secrets" from the script I suspect.

[cw1nte]

Another small observation: in"Keychain Access" I give my password to unlock the Secrets keychain. That has a certain default lifetime, during that time if I want to see my "test" secret I need to give my password again, I suspect this would be true for each secret I have created. ks knows if the keychain is currently in the open state and only results in a prompt when the keychain has timed out/locked. Maybe that is a UI fault in macOS (El Cap or more widely?) generally - this sort of thing happens if I need to give a password to delete each of a list of secured files or similar.

[loteoo]

Hi @cw1nte ! Thanks for your interest, glad you played around with it.

I actually released a new version today (0.4.0) that relates to some of this. Your thoughts were very helpful.

Here's some of my thoughts following up your comments:

As to the "Secret was not found in keychain." errors you're getting - This was probably the result of a bad decision on my part to match for the current user when looking up secrets. This is was bug - thank you for making me realize this 🙏 .

For the "kind" field, you can actually write whatever you want there. The default value is "application password", there is some special filtering in the UI if the value is "secure note", along with a better UI for multi-line.

I removed making "secret" the default value for "kind" and am now using the same default as the Keychain App ("application password") - hopefully this might make it less confusing by making it clearer that it's unrelated with the name of the keychain.

To avoid leaking your secrets to your history when entering them in the command-line, you can pipe from your clipboard (as per readme here), ex: pbpaste | ks add my-secret.

You can also create "secure notes" with the -n flag on the add command, ex: cat long-text.txt | ks add -n my-note.

Hope this helps, thanks again!

[cw1nte]

Nice! The completions feature got me looking into completions in general (not well supported beyond basics in macOS). I like the programmatic completions, via a _ks function that looks at parameters on command line and displays current options. This would allow ks show[TAB] and ks rm[TAB] to show the ls output and then allow user to continue. Next stage is to do partial match so if ks show my[TAB] then all secrets beginning my... (if any) are shown or completed if unique. Ideally autocompleting up to any differences in a multiple possibles list. (eg mySecretOne mySecretOther would complete to mySecretO and show the 2 options?) Bit of work but it would encourage good entry naming and be rather smooth...

[loteoo]

Hey @cw1nte , thanks again for the thoughts. I looked into this but the biggest hurdle is that to obtain this list of secrets, you need to unlock the keychain which will prompt for the password annoyingly.

I'll keep an eye out for alternatives 🙏