[snip] > As mentioned above, any "commitment" made at the present time may > not be relevant in a year's time. What I am able to do will depend > on how much time I have available, what pieces are contributed by > the community, and what features are needed by MIT and the community > as a whole. We plan to prioritize having a functional > implementation that allows the use of GSSAPI with Kerberos 5 as a > mechanism and AES256 as the key type, but other functionality will > be implemented as time permits. If some organization or individual > were to, say, remove LWP dependencies from the source tree in favor > of pthreads, then I would have more time to spend on new features > such as you list here.
What are the roadblocks to standardizing an 'rxk5' transport that supports any encryption mechanism(s) of the underlying kerberos implementation, but does *not* use GSSAPI? Obviously this does not provide everything a full GSSAPI implementation would, but it would provide some basic functionality. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
