development meeting 5/24

[Nico Williams]

[Apologies for hosting this thread on krbdev-release at MIT.EDU.]

To recap the outcome of the meeting:

On Mon, May 23, 2016 at 10:51:26PM -0500, Nico Williams wrote:
> So I guess we have a few questions:
> 
>  - Should we fix the subtle bug I described above?
>    (IMO: yes.)

We agreed that the semantics that Viktor and I proposed are the best,
and MIT agreed to accept patches from us to implement that.  (I'm not
sure that we'll submit any anytime soon -- we're focused on Heimdal at
the moment.)

For MIT this means that krb5_walk_realm_tree() and
k5_client_realm_path() will need to take an extra argument, so that the
path will be identified by: {crealm, this_realm, srealm}.  The [capaths]
list for {crealm, srealm} will be looked up first, then {this_realm,
srealm}, falling back on the hierarchical path from this_realm to
srealm.  On the client side this_realm == null or this_realm == crealm.
On the TGS side this_realm is the second component of the sname of the
TGT used by the client.

>  - Should we implement the multi-value order non-preservation
>    workaround?
>    (IMO: it's more complexity, but if we must deal with this problem,
>    then yes.)

We agreed that we can count on multi-value order preservation.  Either
the profile API should not re-order values when writing, or it shouldn't
be used.  Apparently there are other parameters in krb5.conf for which
order preservation is required anyways.

(ISTR Love telling me that we could not count on multi-value order
preservation.  Love, am I remembering correctly?  Was the motivation for
that the profile API's reordering on write, or something specific to
Heimdal or OS X?)

The release notes for the upcoming release of Heimdal will discuss this.

Note that Heimdal will default the use of implied hierarchical capaths
to off.

It might be nice to have a WELLKNOWN realm whose purpose is to indicate
"hierarchical from the LHS to the RHS", so as to make it easy to write
[capaths] sections where some hierarchical paths are opted-in and
otherwise all opted out.  It's possible to blacklist capaths using a
bogus realm too, so we might want a WELLKNOWN realm for the purpose of
prohibiting a path.

Nico
--