Subject: Re: [kitten] gss_oid_equal and null equality

From: Martin Rex <[email-masked]>
Date: Tue, 19 Apr 2011 18:48:37 +0200 (MEST)

Nico Williams wrote:
> 
> On Apr 18, 2011 4:13 PM, "Martin Rex" <[email-masked]> wrote:
> > I am not convinced that it is sensible to define this, because the
> > "correct" answer is context sensitive and even there potentially
> > debatable.
> > As I said, I implemented the answer to this question twice, the answers
> > differ, and I don't feel a need to change either implementation.
> 
> I understand the desire to avoid changing either implementation that you
> have.  A reasonable compromise would be to say that this I-D documents a
> historically available function and to pick one behavior as RECOMMENDED
> (SHOULD) instead of REQUIRED.
> 
> I would much prefer REQUIREing a single behavior though.

I think I'm OK with this proposal picking a particular implementation
choice and REQUREing that.

Personally, I do hate the "undefined" behaviour with several ISO-C calls
as shipped by several vendors.

   e.g. there are platforms crashing on
       strncpy(valid dest, NULL, 0)
       memcpy(valid dest, NULL, 0)
       sprintf(valid buffer, "%.*s", 0, NULL)

although they actually MUST not crash on this, because dereferencing
any of the source pointer would be accessing contents of an array
outside of the array boundaries, which ISO-C clearly prohibits.

However, I would really appreciate a guidance that callers of
gss_compare_oid() must decide in a context-specific fashion,
whether the answer this function provides if at least one of the
arguments is a NULL OID is appropriate/correct in the given situation.

In many situations, an explicit error handling might be more appropriate.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 20 Apr 2011 12:18:29 +0200

> arguments is a NULL OID is appropriate/correct in the given situation.

What kind of text are you looking for?  The document now says that
GSS_C_NO_OID does not compare positively to itself or anything else.  Is
that not sufficient?  Perhaps it is easier to move forward by
considering some concrete text that you would like to see added.

> In many situations, an explicit error handling might be more appropriate.

To me that means every caller has to work harder to use the interface.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Thu, 21 Apr 2011 18:48:30 +0200 (MEST)

> considering some concrete text that you would like to see added.

OK, I'll try to come up with some text.

> To me that means every caller has to work harder to use the interface.

Nope.  The functionality itself is sufficiently trivial that similar
to any of the oid_set call *I* would never attempty trying to call
an external library for them.  And if the external library doesn't
provide them, because these are new and optional calls, your code
will have to provide them itself anyway.

GSS_C_NO_OID is *undefined* for mechanism OIDs as inputs, and means
"no OID returned" on output.  For nametype OIDs, GSS_C_NO_OID indicates
a "request for default" on input, while on output it also means
"no OID returned" -- it does not mean "default nametype" on output!

So the situation that one is comparing OIDs where one is a GSS_C_NO_OID
does not really make operational sense.  And when you want to explicitly
compare some OID to GSS_C_NO_OID, the currently specified behaviour
gss_compare_oid(GSS_C_NO_OID,GSS_C_NO_OID)==FALSE precludes that
-- the caller will have to special case this to clearly recognize
this situation.

-Martin