[Telepathy] tp_cli_connection_manager_run_request_connection(): What parameter types.

[Jiri Baum]

Hello,

Simon McVittie:
> >  (e.g. "old-ssl" in Gabble, which enables legacy SSL support).
> > It is possible to discover the types via TpConnectionManager (which,
> > behind the scenes, means over D-Bus or from the .manager file), and
> > indeed account-creation UIs will need to do this, but that doesn't help
> > you if you're hard-coding parameters and types into C code.

Murray Cumming:
> But you have to hard code the types either way, and you do that because
> you know what connection manager you are using and what it provides. At
> the moment you must explicitly hard-code the types in the application
> code. I'm just saying that it should be implicit.

The thing is that if the types mismatch, and they're explicit, you'll get an 
error that says so. If the types mismatch and they're implicit, you may get 
your integers being dereferenced as string pointers and the like. Crash at 
best, information leak at worst.

> > There'd also be nothing to stop a CM having the wrong type for a
> > well-known parameter - we'd consider it to be buggy, but that's no
> > reason to let it crash client code remotely.

> I think you should check for that when initializing the connection
> manager. Constraints are good.

You can't really do that when initialising the connection manager, because the 
application doesn't do that - the MC does. The MC might consider a different 
set of parameters to be "well-known" than your application, so you couldn't 
rely on that check even if the MC did make it.

Here you're checking for type mismatch when it's important to you, at the time 
you're setting the values, for those parameters which you consider well-known 
(and therefore hard-code). For the parameters you don't consider well-known, 
you either ignore them or you have code that looks up their types and handles 
them appropriately.


Jiri
-- 
Jiri Baum <jiri at baum.com.au>                   http://www.baum.com.au/~jiri