[Telepathy] tp_cli_connection_manager_run_request_connection(): What parameter types.
jiri at baum.com.au
Tue Oct 28 21:04:23 PDT 2008
> > (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.
> 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
Jiri Baum <jiri at baum.com.au> http://www.baum.com.au/~jiri
More information about the Telepathy