On Monday, 20 March 2017 15:54:42 CET Greg Hudson wrote:
> Thanks again for writing this up.
>
> On 03/20/2017 05:45 AM, Andreas Schneider wrote:
> > The MIT Kerberos library has several symbols which are public but do not
> > offer a prototype in a header file.
>
> Just to be clear, we don't consider functions exported by libkrb5 to be
> part of the public API unless they have a prototype. In most cases
> those symbols are exported for ease of testing or by use in other parts
> of the tree.
>
> [for the Samba kpasswd server]
>
> > decode_krb5_setpw_req
>
> The krb5_setpw_req structure is also not public.
krb5_error_code decode_krb5_setpw_req(const krb5_data *code,
krb5_data **password_out,
krb5_principal *target_out);
This is the function prototype. It doesn't use any internal structures. So I
do not see how someone would need to use the structure you're talking about.
> If the only reason Samba needs its own kpasswd server is access control,
> I would hope that is a temporary need, although we've been very slow to
> create a pluggable access control interface for kadmind's password server.
I would say yes, but I haven't looked into RODC (Read Only Domain Controller)
details yet.
> [for the Samba test suite]
>
> > decode_krb5_error
> > decode_krb5_as_req
> > decode_krb5_as_rep
> > decode_krb5_padata_sequence
> > krb5_free_kdc_req
> > krb5_free_kdc_rep
> > krb5_free_pa_data
>
> We have krb5_rd_error() which wraps decode_krb5_error(). This and
> krb5_mk_error() exist for applications which use KRB_ERROR messages in
> their protocols, such as kprop.
>
> One option would be to add similar krb5_rd_kdc_req(), krb5_rd_kdc_rep(),
> and krb5_rd_padata() wrappers, or some variation along those lines. The
> argument against doing this is that libkrb5 isn't designed to be a
> nuts-and-bolts encoding library for test suites. I've done some
> preliminary work on a Python library for this purpose, but I stalled out
> after implementing the crypto layer.
I would be happy to be able to do all of this in python :) I do not think we
need new functions here.
> A more conservative option, in the sense of not making a long-term API
> commitment, would be to create a new public header marked as unstable
> across releases, containing prototypes for a set of encoding and
> decoding functions, and perhaps some formerly private structures such as
> krb5_setpw_req.
Just having a header which states that it will not have a stable API would be
fine with me.
> I would welcome opinions from other Kerberos developers.
Thanks for considering,
Andreas
--
Andreas Schneider GPG-ID: CC014E3D
Samba Team asn at samba.org
www.samba.org