Matt: The opinion that OpenAFS should not be in the business of maintaining is own private crypto layer or kerberos layers have been voiced repeatedly over the years at best practice workshops and hackathons. The reasons are as follows:
* implementations that are used by a broader range of projects are more likely to be given significant scrutiny resulting in faster detection of bugs and production of optimizations. * projects that are dedicated to implementing RFC 3961 implementations will do the required work for us when new encryption algorithms and checksum algorithms are adopted by the IETF. * projects that are dedicated to implementing RFC 4120 will do the required work for us when new protocol additions and encryption types are added to Kerberos. * There has been consensus in the OpenAFS community for years that OpenAFS is not in the Kerberos business. While OpenAFS is dependent upon Kerberos implementations, the efforts to improve Kerberos implementations should occur upstream in the projects that produce those implementations. As agreed to at the hackathon, Simon will have hcrypto ready for importation onto OpenAFS master at the same time that the master branch will be open to accepting rxk5; after the 1.6 branch is split off from the existing master. Until that time, master is closed to work that is not going to be included in 1.6. Jeffrey Altman Matt W. Benjamin wrote: > 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
smime.p7s
Description: S/MIME Cryptographic Signature
