[17349] in Kerberos_V5_Development
Re: Extensible kadm5 policies
daemon@ATHENA.MIT.EDU (Nico Williams)
Mon Oct 31 17:47:29 2011
MIME-Version: 1.0
In-Reply-To: <ldv39e8q2fc.fsf@cathode-dark-space.mit.edu>
Date: Mon, 31 Oct 2011 16:47:23 -0500
Message-ID: <CAK3OfOjKG7Rx1FRH=POO_1GfPxWGhOCooh51yBjOW=zpVP0Nww@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Tom Yu <tlyu@mit.edu>
Cc: krbdev@mit.edu, Simo Sorce <simo@redhat.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Mon, Oct 31, 2011 at 4:25 PM, Tom Yu <tlyu@mit.edu> wrote:
> Nico Williams <nico@cryptonector.com> writes:
>> I must say that I'm not too upset by the idea of adding a new kadm5
>> API version and doign more type overloading *in MIT krb5*. It would
>> never happen in Heimdal, but we can break kadm5 ABI there, so that's
>> not a big deal. But for the db2 backend I'd still propose
>> policies-as-principals just so we can get policy iprop.
>
> We make far weaker stability assurances for the admin API than we do
> for the krb5 API. Where I do want to try to maintain backward
> compatibility is in the protocol.
A lot of people make use of the kadm5srv API. Breaking them (us) will
annoy them (us). But I guess it's OK.
I'd need a *lot* more guidance if what you want is a brand new API. I
may also simply not implement it if it would be too much work, and we
may simply continue with our current hack (of embedding additional
policy information in the policy name).
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
