export list symbols

[Nicolas Williams]

I think I missed that these were functions not listed in krb5.h.  If a
function is in a private header then I agree that automated static
analysis is sufficient for deciding whether to make it not an exported
symbol.  Except for private-that-should-be-public symbols, of course,
but that can be revisited later.

On Tue, Oct 20, 2009 at 11:57:06AM -0400, Greg Hudson wrote:
> > any function that seems private, but
> > which actually implements an interface from RFC3961 should be public
> > since there may be krb5 applications and/or plugins that need them.
> 
> If people agree that we should provide public APIs for all RFC 3961
> operations we implement, then we can prototype these in krb5.hin,
> possibly under new names.  (We don't actually use krb5_derive_random
> anywhere, so that would become the only use of that function.)

Well, MIT krb5 has a plugin interface for preauth methods.  Pre-auth
methods may well (and PKINIT sure does) make use of RFC3961 interfaces.
Ergo RFC3961 interfaces should really be exported, at least to plugins.
It's hard to export to plugins but not to apps, but it can be done if
you have the framework pass a set of function pointers to the plugin
(and you can always segregate for-plugin vs. for-all declarations by
header).

But also, RFC3961 is not intended to be a mere detail of Kerberos
protocol construction: "raw" krb5 apps that extract session keys and
make use of krb5 enctypes directly are legitimate users of RFC3961.

Think of TELNET and AFS, which, I know are not exactly good examples
here (in large part because they pre-date RFC3961), but they are good
examples of apps which, if they really had to avoid KRB-SAFE/PRIV or the
GSS-API (e.g., because of per-token/message overhead), then really
should have used _a_ cryptographic protocol framework, of which RFC3961
is a reasonable example.

IMO Kerberos implementors SHOULD export RFC3961 interfaces.

Nico
--