working long-term with the MIT KRB5 codebase in the AD DC

[Uri Simchoni]

I tried building Samba against master MIT, to get a sense of what it
takes, and and failed in a quite puzzling way. The failure doesn't seem
related to AD-DC. My steps were:

1. Build git-cloned MIT with --prefix=/home/uri/krb5inst:
a. autoreconf
b. configure --prefix=/home/uri/krb5inst
c. make
d. make install
2. Run an autobuild-ish samba configure:

./configure.developer --with-selftest-prefix=./bin/ab --picky-developer
--with-profiling-data --prefix=/home/uri/s2/bin/samba/prefix
--with-system-mitkrb5 /home/uri/krb5inst --with-system-mitkdc
/home/uri/krb5inst/sbin/krb5kdc

The resulting build failed at lib/krb5_wrap/krb5_samba.c with:

/home/uri/krb5inst/include/profile.h:343:33: error: unused variable
‘et_prof_error_table’ [-Werror=unused-variable]
 extern const struct error_table et_prof_error_table;
                                 ^~~~~~~~~~~~~~~~~~~
/home/uri/krb5inst/include/profile.h:40:15: error: typedef
‘profile_filespec_t’ locally defined but not used
[-Werror=unused-local-typedefs]
 typedef char* profile_filespec_t; /* path as C string */
               ^~~~~~~~~~~~~~~~~~
/home/uri/krb5inst/include/profile.h:41:15: error: typedef
‘profile_filespec_list_t’ locally defined but not used
[-Werror=unused-local-typedefs]
 typedef char* profile_filespec_list_t; /* list of : separated paths, C
string */
               ^~~~~~~~~~~~~~~~~~~~~~~
/home/uri/krb5inst/include/profile.h:288:3: error: typedef
‘profile_module_init_fn’ locally defined but not used
[-Werror=unused-local-typedefs]
 (*profile_module_init_fn)(const char *residual, struct profile_vtable
*vtable,
   ^~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

I repeated this with Fedora 27 beta - success with system MIT Kerberos,
failure with master MIT.

Usually I'm able to figure out these things but this time I was left
puzzled - same compile switches, "offensive" typedefs and variables in
both versions (as seen in pre-processed code), yet the system krb5
succeeds and my own-built one fails. The only difference in compiler
flags is -I/home/vagrant/krb5inst/include

Thanks,
Uri.

On 10/20/2017 09:56 PM, Jeremy Allison via samba-technical wrote:
> So there's a tension here between the needs of distro's and the needs
> of vendors (I'm considering Catalyst via Andrew as a specific Samba
> vendor here).
> 
> Distros need Samba to work with the libraries shipped with the distro.
> An "upstream first" policy for all dependent libraries is a must.
> 
> Vendors need flexibility to add new features to both libraries and
> Samba to work with them. That sometimes means prototyping features
> and after customer approval getting the changes pushed upstream.
> 
> I don't want a fork of MIT. No one wants to fork important security
> libraries anymore. I don't want to keep a copy of Heimdal anymore. I
> think we can all agree on this :-).
> 
> Moving both Heimdal and MIT to a git reference to an external tree is
> a good idea.
> 
> My guess is the difficulty comes from this statement in Andrew's
> email:
> 
>> What I propose is:
>> - Our build system uses a git reference (via a submodule or otherwise)
>> to check out and build MIT krb5
>> - In Samba master, this tracks either:
>>   - MIT master
>>   - a "
>> - In Samba release branches this tracks:
>>   - the release branch, the released version of MIT krb5 that we will
>> support
>> - This occur in parallel to the Heimdal build
> 
> what we need to determine is what "Samba vendor fork of
> MIT in limited circumstances" actually means.
> 
> So long as this *doesn't* mean "a copy of MIT in our tree on samba.org"
> I hope we can come to some compromise we can agree on.
> 
> I see some hope in Andreas's reply here:
> 
>>> What I propose is:
>>>  - Our build system uses a git reference (via a submodule or otherwise)
>>> to check out and build MIT krb5
>>
>> That's fine just for development!
> 
>>>  - In Samba master, this tracks either:
>>>    - MIT master
>>>    - a Samba vendor fork of MIT in limited circumstances
>>
>> That's extremly bad! An enterprise distribution will not allow a vendor fork
>> of MIT Kerberos. You use what is in the system or not.
> 
> Can we get some consensus on what "is fine for development" means
> to both of you ?
> 
> Andreas, how do you see Andrew being able to add needed features
> to AD+MIT to move our MIT implementation forward ?
> 
> Andrew, how do you see being able to separate this out from
> master so the distros can keep a supported Samba running against
> the default shipped and supported crypto libraries ?
> 
> Jeremy.
>