[OpenAFS-devel] A crypto layer for OpenAFS

[Matt W. Benjamin]

Hi Simon,

Only the ones I shared with the hackathon participants.  This summary neglects to mention that the rxk5 work, which faced this issue in 2005, already produced a portable crypto bundle called k5ssl in 2006, which has already been submitted upstream and requested for inclusion as well--because rxk5 already works with it.

It's possible I really am missing something, since perhaps making hcrypto work in all our supported Unix kernels, as k5ssl does, may not be a very large project.  However, does what's being imported -already- do this today?  If it does, great.  If it does not yet, why would we

a) import hcrypto before it works for its intended purpose
b) delay importing what does work with rxk5

I apologize for restating these questions from earlier this morning in the other context, but, this post to devel sans context isn't an answer to the them.

Regards,

Matt

----- "Simon Wilkinson" <sxw@inf.ed.ac.uk> wrote:

> There are a number of pending projects which require OpenAFS to have 
> 
> better crypto support, particularly within its kernel module. Whilst 
> 
> on some platforms we may be able to take advantage of native kernel  
> implementations, on others suitable alogrithms are not available, and 
> 
> on some, even if code is available, we are prevented from using it by 
> 
> a license wall.
> 
> So, we pretty much need our own implementation of the common crypto  
> algorithms. It would also be nice if someone else would look after  
> them for us, so we aren't responsible for even more code. Sadly, as we
>  
> need this in kernel, we can't just use a library. However, Heimdal  
> does have a nice crypto subsystem - hcrypto, which can be compiled for
>  
> in kernel use.
> 
> Assuming we go with hcrypto, the issue becomes one of source code  
> management. Sadly, we can't use git submodules for this, because doing
>  
> so would require pulling in the whole Heimdal tree to compile
> OpenAFS.
> 
> 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.
> 
> Comments?
> 
> Simon.
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309