Heimdal Futures

[Andrew Tridgell]

Andrew,

 >  - SVN link (reverence, or whatever) the current repository from
 > lorikeet into samba4

I've never setup a svn link, so I'm not sure how it works and what the
disadvantages might be. If it means a standard checkout gets all of
heimdal I would not like this option.

 >  - SVN import the entire lorikeet/heimdal repository into samba4

I really don't want to do this, as explaied below

 >  - SVN import only the files we currently compile into samba4

This is my preference.

The main reason is the huge disparity between the code we need from
heimdal and the total size of the whole of heimdal. Here are the
approximate numbers:

 - all of heimdal:           1600 files 
 - bits of heimdal we need:  270 files
 - current samba4 source:    800 files

so we would be tripling our code size to add kerberos. Two thirds of
the resulting source tree would not be used in Samba.

This huge disparity has consequences for developers. For example, I
use etags and other source code navigation tools to work efficiently
with the source tree. Having 2/3 of all of the code being "dead wood"
would greatly reduce the effectiveness of those tools. This is made
worse by the fact that a large number of symbols in the dead code are
in common with symbols already in Samba, due to the fact that heimdal
has its own extensive portability library that defines many of the
same functions as we define in Samba.

What I would like to propose is to import only the files we need. We
would import them as whole files, with zero modifications from the
same filenames in the heimdal tree. This makes updating our import
from the upstream heimdal tree much easier (it can easily be scripted)
as the paths remain the same, and there are no local modifications.

We would still test a standalone heimdal on the build farm, just as we
do now. That allows us to ensure we can differentiate between bugs
that are due to the embedding of heimdal and bugs in the upstream
source.

We need a kdc, and we need krb5 client libs, but we don't need a POP
implementation and a telnet implementation from heimdal. We also don't
need rsh, rcp or ftp. We have enough trouble managing our source tree
without grep showing up socket calls in a ftp implementation and
having to discard them when looking for blocking socket issues.

It will also be really horrible explaining this to security auditors
who will search our code base for vulnerabilities. It will quickly get
tiring to explain that 2/3 of our code is unused.

Cheers, Tridge