export list symbols

[Greg Hudson]

On Tue, 2009-10-20 at 10:39 -0400, Zhanna Tsitkova wrote:
> krb5_c_weak_enctype

Tom, you prototyped this in k5-int.h but otherwise defined it in a way
appropriate for an API function.  What was your thinking on this?

In my opinion, we shouldn't define internal functions with "might become
part of the API in mind"; it's better to rename the symbol in the future
if and when we decide to actually put it in the API.

> krb5_encrypt_data

krb5_encrypt_data, krb5_decrypt_data, and krb5_random_confounder are
"old APIs" which aren't actually prototyped in krb5.h (they are
prototyped in k5-int.h).  If we're going to rename them, we may as well
delete them.  I'm all in favor of deleting them, but maybe somebody
knows some history about them to suggest that would be a bad idea.

(Actually, we use krb5_encrypt_data in two places in the preauth
framework, but we should stop that.)

> krb5_derive_random

Oddly, we don't seem to use this anywhere but in a test program.  Does
anyone know what it's for?

Nico wrote:
> How do you know this?  There may be third party apps that do use these
> symbols, even if that seems wrong.  Some interfaces may be legacy;
> some should never have been exported but were.

Our policy has generally been that if a symbol isn't prototyped in
krb5.h, it isn't a stable API even if it begins with "krb5_", although
we should rename it if we change the symbol's API or ABI.  (This is so
that apps at least break cleanly if they used it, and so that
configure-time tests don't find it in the library.)

We've made use of this policy in the past, such as renaming
krb5_send_tgs to krb5int_send_tgs for the FAST work in 1.7, and so far
haven't received any negative feedback on it.  If people have
case-by-case reasons to believe that someone has used a particular
symbol despite the lack of a prototype, then we should preserve
compatibility, but I don't want to be paralyzed by the faint possibility
that someone might have done so in every case.

Nico specifically mentioned:
> krb5_nfold
> krb5_derive_key
> krb5_derive_random
[...]
> 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.)

I should note that as part of the enc-perf work I changed the signatures
of krb5_derive_key and krb5_derive_random, and also krb5_hmac.  So those
should definitely be renamed; I will make a note to make sure that gets
taken care of before 1.8.