On Wed, 2018-10-31 at 01:13 -0700, Yoshimasa Niwa wrote: > I see. This patch is using internet password type item in Keychain, > which has username and URL as a key and password as a value. > However, we can use a generic type item instead, to store secrets in > the flexible scheme. > In that case, probably I will change the patch to like this: > > 1) Change `--use-keychain=...` to take Keychain entry name, not > password form field name. For example, `--use-keychain=companyvpn` > 2) When it sees each password form field, lookup Keychain with given > entry name and if exists, load the value. If not, ask it on tty, then > store it in Keychain, if the user wants. > For example, if we see "formname:password" form field, then ask it on tty, then > ask to want to save to Keychain or not, then if the answer is yes, > create a generic type item like: > key: service=openconnect, account=companyvpn, generic=formname:password > value: (value from tty) > > Slightly complicated than the current patch, but I think this approach > is much more flexible and works better with suggested `--formentry` > option..? Hm... or maybe only the 'password' type fields should be stored in keychain and every other form field can be provided on the command line? Those ones aren't secret, after all. We do still need to allow for the fact that there might be multiple passwords though (and one day, maybe some saveable and some not, for example a password and a separate OTP). But specifying on the command line which password(s) to save would be OK, I think? FWIW what I'd *really* like to see is SSL certificate support using the keychain... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20181101/eb2e9004/attachment.bin>
