[OpenAFS-devel] A crypto layer for OpenAFS

[Marcus Watts]

> Date:    Fri, 09 Oct 2009 12:14:37 PDT
> To:      afs Devel <openafs-devel@openafs.org>
> From:    Russ Allbery <rra@stanford.edu>
> Subject: Re: [OpenAFS-devel] A crypto layer for OpenAFS
> 
> Simon Wilkinson <sxw@inf.ed.ac.uk> writes:
> 
> > What I'd like to propose is that we pull in release version of hcrypto
> > into src/thirdparty/hcrypto. The only commits that would be permitted
> > into this portion of the tree are ones which take hcrypto from a later
> > Heimdal release, and update our local copy. That is, any native
> > modifications we require to hcrypto would have to be made upstream.
> 
> This is definitely the approach that I support.  From my perspective, it's
> very important that we don't get ourselves into maintaining our own crypto
> layer; we should just use someone else's.  I like the idea of using
> Heimdal's because it's actively maintained and is already adapted for
> kernel use, and it has a community and usage with significant existence
> outside of OpenAFS, so it's unlikely that we'll get stuck having to
> maintain it down the road.  Having the restriction that we don't maintain
> local patches is very important to avoid slipping into maintaining it
> ourselves.

There are any number of java projects I've seen at this point which
have some sort of "3rdparty" branch with random jar files from
other projects.  I could go on at great length about all the evil
things that result.

If what you have does not require significant local patches, then
you should use heimdal as an external package.  This makes it easier
for other sites to pull down a later version of heimdal, or to use
some other version of heimdal that they already have, rather than
installing multiple heimdals, one for openafs, one for other stuff.
If you don't want to support your own copy of kerberos, then this
is clearly the model you want.

	If you do this, you can say "tested / supported with version
	X.Y.Z of heimdal (provided X.Y.Z tends towards the stable
	release.)  You can distribute small patches to provide AFS
	specific functionality, provided they are in a form the heimdal
	maintainers could accept.  That means the patches should include
	sufficient testability that the maintainers could verify patch
	functionality without the need to learn anything about AFS other
	than what it needs from heimdal.

If what you have does require sigificant local patches, then you have
forked heimdal.  Embrace it.  Have src/hcrypto.  Don't call it
src/3rdparty/hcrypto, that just ghetto-izes it, which does nobody any
good.  You can still share patches and get much of the goodness of
having somebody maintain core non-AFS functionality.  

	This is not a one-time effort.  It will require a
	significant ongoing effort to keep it up to date.

Depending on how you count things, in OpenAFS you have at least
these 3 "worlds" of code to maintain:
	userland lwp
	userland pthread
	kernel
for userland (lwp or pthread) you should be able to use a nearly
unmodified heimdal.  Therefore, the main problem is the kernel,
where you need to solve,
	restricted library subset
	non-posix functions with weird semantics
This last part is probably your hardest problem to solve (ie, malloc/free
etc.).  Choosing your subset carefully will allow you to dodge problems
like DNS in the kernel, but may require careful negotiation with heimdal
maintainers who may be tempted towards scope creep.

				-Marcus Watts