Subject: Re: [kitten] GSS-API additions?

From: [email-masked]
Date: Fri, 1 Apr 2011 15:00:11 -0400 (EDT)

> I know this document has expired, but I don't recall if there were
> any discussion or conclusion on it.  The APIs are implemented and
> deployed in Heimdal and Shishi for some time now (years), and the
> calls are useful for GS2 implementers.  Is there interest in moving
> this forward in this WG?  I believe it makes sense to at least
> publish it as informational because it is widely deployed.

The C bindings use "const" in ways which apply to the pointer argument
rather than the data being pointed to.  For instance, in:

     extern int
     gss_oid_equal (
       const gss_OID first_oid,
       const gss_OID second_oid
     )

the implementation of gss_oid_equal will not be allowed to reassign
its local first_oid or second_oid variable, but will have no problems
modifying the OIDs.  (You can verify this pretty easily by
experimentally changing the implementation and seeing which operations
cause your compiler to error.)  This behavior is sufficiently useless
that I've seen it generates warnings in some environments, although I
can't seem to find one at the moment.

There are two fairly compelling arguments for leaving this alone:

  1. There are already implementations in the field.

  2. This is an error already committed in RFC 2744, and there's
  something to be said for being consistent with your past mistakes.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 01 Apr 2011 22:44:44 +0200

> can't seem to find one at the moment.

Good point.

>   something to be said for being consistent with your past mistakes.

Agreed.

If we _really_ wanted to fix this, I think it could be done without too
much damage to the deployed base: adding a 'const' at the right place
doesn't change the ABI since the function was never permitted to modify
the OID content anyway.

On the other hand, RFC 2744 has the same issue in so many places (a
quick count indicate that around 10 of the APIs seems to have the same
issue) that fixing only this API will make it stand out as odd.

So if there aren't significant problems with how the APIs in RFC 2744
are used, this API will likely not cause any problem either, I think?

/Simon

---

From: Luke Howard <[email-masked]>
Date: Sat, 2 Apr 2011 12:13:37 +1100

>  something to be said for being consistent with your past mistakes.

Not always. RFC 5587 fixed this: use gss_const_OID.

-- Luke

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sat, 2 Apr 2011 20:37:51 +0000

> are used, this API will likely not cause any problem either, I think?

Let move the const-ness to the right place since since it wont change the ABI and will catch mistakes however unlikely.

Love

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 03 Apr 2011 09:20:30 +0200

Love Hörnquist Åstrand <[email-masked]> writes:

> Let move the const-ness to the right place since since it wont change
> the ABI and will catch mistakes however unlikely.

Works for me, as it doesn't affect the ABI.  Any preference on whether
we should use

1) 

  extern int
  gss_oid_equal (
    const gss_OID_desc *first_oid,
    const gss_OID_desc *second_oid
  )

or

2)

  extern int
  gss_oid_equal (
    gss_const_OID first_oid,
    gss_const_OID second_oid
  )

and reference RFC 5587?

/Simon

---

From: Luke Howard <[email-masked]>
Date: Sun, 3 Apr 2011 17:30:39 +1000

2)

Greg: do you want me to update trunk with this?

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sun, 3 Apr 2011 17:32:59 +1000

> Works for me, as it doesn't affect the ABI.  Any preference on whether

Also, you planning to change the others?

OM_uint32 gss_encapsulate_token
(
    gss_const_buffer_t, /* input_token */
    gss_const_OID      /* token_oid */
    gss_buffer_t  /* output_token */
);

OM_uint32 gss_decapsulate_token
(
    gss_const_buffer_t, /* input_token */
    gss_const_OID,      /* token_oid */
    gss_buffer_t        /* output_token */
);

int gss_oid_equal
(
    gss_const_OID,      /* first_oid */
    gss_const_OID       /* second_oid */
);

-- Luke

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 03 Apr 2011 09:41:48 +0200

> Also, you planning to change the others?

If we change one, I think we should change all.  Any reason not to?

/Simon

---

From: Luke Howard <[email-masked]>
Date: Sun, 3 Apr 2011 17:46:57 +1000

> If we change one, I think we should change all.  Any reason not to?

Nope, change 'em all! I can check some fixes in for both Heimdal and MIT.

-- Luke

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 03 Apr 2011 11:39:30 +0200

I've submitted -03 that uses the RFC 5587 types, thanks Greg and Luke.
Please take a look whether the changes are correct:

http://tools.ietf.org/rfcdiff?url2=draft-josefsson-gss-capsulate-03.txt

/Simon

---

From: Luke Howard <[email-masked]>
Date: Sun, 3 Apr 2011 20:36:34 +1000

Looks good. Thanks for the acknowledgment! Now, should we do the same for naming extensions... (except MIT has shipped with the non const ones, but as Greg pointed out there are no ABI issues).

Von meinem iPhone gesendet

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 03 Apr 2011 13:02:05 +0200

Luke Howard <[email-masked]> writes:

> Looks good. Thanks for the acknowledgment! Now, should we do the same
> for naming extensions... (except MIT has shipped with the non const
> ones, but as Greg pointed out there are no ABI issues).

Making the change elsewhere seems like a good idea to me.  I wish we had
noticed the bug for the RFC 5801 interfaces as well.  Possibly we could
submit an errata about it, and fix it in 5801bis?

(..and RFC 2744..)

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 11 Apr 2011 12:17:07 +0100

>submit an errata about it, and fix it in 5801bis?
Sure.