[PATCH] Fix new DBus API

[Sam Leffler]

On Mon, Apr 4, 2011 at 7:16 PM, Dan Williams <dcbw at redhat.com> wrote:

> On Thu, 2011-03-31 at 13:48 -0700, Sam Leffler wrote:
> > On Thu, Feb 3, 2011 at 8:42 AM, Dan Williams <dcbw at redhat.com> wrote:
> >         On Tue, 2011-02-01 at 18:45 +0200, Jouni Malinen wrote:
> >         > On Wed, Jan 05, 2011 at 12:08:02PM +0200, Tomasz Bursztyka
> >         wrote:
> >         > > "psk" field, in set_network_properties(), was always
> >         getting quoted even when
> >         > > containing a raw key (64 characters length representing
> >         the hexadecimal value
> >         > > of the raw key).
> >         >
> >         > Dan described the design here and it sounds reasonable to
> >         allow this as
> >         > an alternative approach. However, there is something here
> >         that looks a
> >         > bit odd to me..
> >         >
> >         > > @@ -273,11 +286,12 @@ static DBusMessage *
> >         set_network_properties(DBusMessage *message,
> >         > >             } else if (entry.type == DBUS_TYPE_STRING) {
> >         > > -                   if (should_quote_opt(entry.key)) {
> >         > > -                           size =
> >         os_strlen(entry.str_value);
> >         > > -                           if (size <= 0)
> >         > > -                                   goto error;
> >         > > +                   size = os_strlen(entry.str_value);
> >         > > +                   if (size <= 0)
> >         > > +                           goto error;
> >         > >
> >         > > +                   if (should_quote_opt(entry.key, size,
> >         > > +                                        entry.str_value))
> >         {
> >         >
> >         > Why is size == 0 an error? I'm not sure it was correct with
> >         the previous
> >         > quote case either, but now any use of DBUS_TYPE_STRING would
> >         trigger an
> >         > error if the string is empty. There are number of
> >         configuration
> >         > parameters for which an empty string is a valid value. Am I
> >         missing
> >         > something or how is this supposed to work for such cases?
> >
> >
> >         That wasn't something I'd recognized originally; what are
> >         those
> >         properties and what's the motivation for them?  Are these
> >         things where
> >         just the presence of the property is important, but the actual
> >         value
> >         isn't know at this time, or...?
> >
> >
> >
> > This seems to have been dropped.  The raw PMK fix that triggered this
> > exchange never got committed and is useful so can we resolve the issue
> > with zero-length strings?
>
> I'm not sure I follow.  In what situations is a zero-length string
> useful as a property?  I'm not saying it's not useful, I'm just trying
> to figure out what problem this fix is trying to work around?


I think this question is to Jouni regarding the original code that generated
an error on zero-length strings.  I don't have an answer--am mostly trying
to isolate that issue from the PMK change that we've adopted for Chrome OS
but which looks to have been dropped.

-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20110404/d872ac33/attachment.htm