> No, the --formentry options would contain the field name and the actual > answer. For example > --formentry main:user=dwmw2 --formentry main:group=foo > Using keychain would be a separate option. Ah, got it. > Hm, take a look at the way NetworkManager-openconnect constructs the > 'key' for looking up this data. That just uses $FORMNAME:$FIELDNAME in > the style I've been using in my examples above.... 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..? Y -- Yoshimasa Niwa
