Hello Jan,

Thanks for the detailed account, good to have an idea of
the state of things.

On Thu, Jul 10, 2014 at 03:56:24PM -0400, Jan Harkes wrote:
> Maintenance patches have been merged into both CVS and Git repositories
> whenever needed, but no major releases have been pushed out. This is
> partly because of lack of time and partly because the current source
> repository situation,

:(

> Switching to Git as the canonical repository would simplify life
> considerably, but the existing Git repo may not be the right one to
> use for this. For one it doesn't accurately track the full history. I
> tried to import as much history as I could from CVS, but especially the
> very early history is not correct. For the longest time we actually have

Do you mean that the import would have to be redone into another, fresh
git repository? How possible/painful is to do this?

> a negative LoC count on Ohloh but it looks like they managed to fix that.

Ooh.

> Oh and I wanted recently to push at least a source level release out of
> the door because of a fix for a filedescriptor leak that over time kills
> I used to use to tag, build, sign and package new releases have broken
> and I still have to decide if I want to glue the pieces back together or
> just rewrite them.

Sigh.

> About the modular clog code, I don't know what the current state of it
> is. I haven't looked at it since some very early versions, of which I
> have a vague recollection that I thought were a bit complex and hacky.

Yes it is more complex inside than the vintage clog/authd - as much
as necessary to tackle the crucially needed degrees of freedom.

It held actually its promises, not revealing any apparent limitation
or a crucial bug over the years. (IIRC there was one logic error in
the handling of the Kerberos service principals, bad enough to allow a
Kerberos spoofing attack but was easy to fix)

The krb5gssapi module was never used here and hence is untested (IIRC
the gss library was relying on pthreads which did not play well with
the non-pthreaded kerberos libs) but that module does not seem to be
necessary, given clog-module-kerberos5. At Chalmers we steadily exercise
most of the clog modules on hundreds of clients and the daemons on
about a dozen servers (more daemons than the servers as we run one
auth daemon process per each authentication authority).

> I recall that it really needed some better/more portable representation
> of a Coda token that could get passed from module to module, not sure if

The current representation is indeed extremely simplistic but I
never encountered a situation where it would be inadequate. No, we
never used it between computers of different endianness - but the
endianness-robustness of a Coda token should be probably addressed at
a different level (it should be addressed in any case).

> that ever got implemented I think the existing exported token had an
> endianess issue.  But again I have not looked at modular clog for at
> least 8 years if not more and I haven't seen any patches for them.

Looking at the "modular clog" patch:
"53 files changed, 7578 insertions(+), 280 deletions(-)"
which is of course quite a challenge to review.

If you would like to take a look at it I will be glad to send it to you
(ca 50k compressed).

Regards,
Rune