working long-term with the MIT KRB5 codebase in the AD DC
uri at samba.org
Sun Oct 22 13:07:51 UTC 2017
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:
b. configure --prefix=/home/uri/krb5inst
d. make install
2. Run an autobuild-ish samba configure:
./configure.developer --with-selftest-prefix=./bin/ab --picky-developer
--with-system-mitkrb5 /home/uri/krb5inst --with-system-mitkdc
The resulting build failed at lib/krb5_wrap/krb5_samba.c with:
/home/uri/krb5inst/include/profile.h:343:33: error: 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
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
typedef char* profile_filespec_list_t; /* list of : separated paths, C
/home/uri/krb5inst/include/profile.h:288:3: error: typedef
‘profile_module_init_fn’ locally defined but not used
(*profile_module_init_fn)(const char *residual, struct profile_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
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
>> 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
>> - 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 ?
More information about the samba-technical