On Sat, 2018-11-03 at 22:37 -0700, Yoshimasa Niwa wrote: > > 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. > > Yeah, I agree. Keychain should only fill the password type field. > > > 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? > > Yes, that's why I mentioned in previous email asking user to save it > or not in Keychain, > but giving it as an argument would be better option. > I knew it because for my personal usage, the form requires two passwords and > one is for OTP as exactly what you described. > Let me change a little bit more on my patch. Some of this is already handled by the UI authentication tools. The NetworkManager auth-dialog, for example, already stores the form entries and uses libsecret for password fields. Although it doesn't support selectively storing *some* password fields and not others. (At least, not except by using the trick of turning the 'save passwords' option off manually instead of through the UI so that the saved passwords aren't cleared, then manually clearing the password(s) that you don't want to be stored...) I think a --use-keychain argument which either stands alone *or* takes a field name in the same form as the '--form-field' I just added in the 'fields' branch, might make sense? Do we need to allow OpenConnect to *write* those secrets to the keychain/libsecret too? Or is reading them sufficient? > > FWIW what I'd *really* like to see is SSL certificate support using the > > keychain... > > Looks like GnuTLS has common API that is for supporting system key > store, however, > according to their documents, it?s at this moment only supporting Windows one. > I think it may be not much difficult to use Keychain to lookup > certificates and keys > like what current `ANDROID_KEYSTORE` does. > Let me try after implementing above changes for passwords. Yeah, whatever we do here, we'd be looking to Nikos to include it in GnuTLS. The TPMv1 code in OpenConnect might make a reasonable example here ? we just need to provide a gnutls_privkey_t with a suitable sign_func that calls into the keychain functions to actually do the signature. Unlike TPM we presumably want to support *certificates* from the keychain too rather than just private keys. But that should be even easier; certificates are public so we just need to obtain the data and populate a gnutls_x509_crt_t with it. Note that the ANDROID_KEYSTORE support predates the Android keystore actually doing anything sane ? it assumes you can actually read the private key data from the store, instead of being limited to performing *operations* using it. We should probably fix that up one day... -------------- 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/20181104/92638ff3/attachment.bin>
