On Wed, Jan 29, 2014 at 10:59:21AM +0000, Simon McVittie wrote: > reassign 699103 telepathy-rakia 0.7.4-1 > tags 699103 + upstream > thanks > > On 28/01/14 20:06, Ron wrote: > > Yes, I think I'm a bit leery about unilaterally (and otherwise silently) > > changing the trust path of all applications using this lib. > > Fair enough, taking this bug back. It's going to have to be an upstream > feature request, in that case.
Feel free to keep me in the cc for any discussion. I'm not disinterested in this, just far less certain that there is One True Answer that is correct for all applications using the lib. Who you trust to serve you web pages may not be the same as who you trust to secure your comms. And likewise who you trust may not be the same for all comms applications. So it really seems like a per-app thing. Having a fallback that should be empty by default seems like a lesser wrong - but having it shared by all apps still seems kind of wrong unless the user said they explicitly wanted that for them. > > I'm not all that familiar with telepathy-rakia, but most apps should > > probably be setting this explicitly with NUTAG_CERTIFICATE_DIR or > > similar (depending on which interface set they are using). > > /**@def NUTAG_CERTIFICATE_DIR(x) > * > * X.500 certificate directory > ... > * @par Values > * NULL terminated pathname of directory containing agent.pem and > cafile.pem files. > > So rakia will have to create a directory $certdir (either global or > per-account), symlink /etc/ssl/certs/ca-certificates.crt -> > $certdir/cafile.pem, and pass NUTAG_CERTIFICATE_DIR($certdir) to > nua_create(). Is that correct? Or you could just pass it the system dir directly if that's what you want, but yeah, that's how I understand this should work (and how I do it in my code). The hardcoding of 'cafile.pem' and 'agent.pem' as the files it looks for is an unfortunate limitation that I certainly wouldn't be sorry to see fixed. But only needing to pass a dir is one form of keeping it 'simple' I guess. > This seems more complicated than it needs to be, but entirely feasible. I'm not sure what you see as complicated there? I assume rakia already has a mechanism for other user selectable configuration passed to this, it just needs a cert_dir option, which may or may not have a default if the user doesn't set it - whichever you decide is best. The user certainly should be able to override this if they want to. Or do you just mean having to futz around with creating the needed dir and file structure? > smcv wrote: > >> The ideal solution would be if telepathy-rakia could additionally use > >> the Telepathy ServerTLSAuthentication interface to tell UIs "this > >> certificate looks wrong, please deal with it" - that's what > >> telepathy-gabble does. > > Does sofia-sip have any functionality for this? It would probably be an > API intended for browser-style interactive prompting; in Telepathy we > proxy that over D-Bus, so the application checking the cert is not > necessarily actually interacting with the user, but we have the same > requirements as user-interaction in terms of "must be asynchronous". I > suspect it doesn't have this API, though? If it does, then I'm not aware of it either, yeah. You can set TPTAG_TLS_VERIFY_POLICY to specify the automatic response to various TLS failure modes, but there's no hook for an external or interactive controller for that. To add one, you'd probably want to look in tls_verify_cb in tport_tls.c (which is the openssl verification callback). Though I'm not certain offhand exactly what that will block if it has to wait for user input before knowing exactly how to proceed. Hopefully it _should_ just be that one socket connection thread. So this should be doable. But not without a new API hook for it. Unless I'm missing something obvious. Cheers, Ron -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
