 |
|
|---|
We welcome contributions from the open source community to help advance the OpenAFS project. The roadmap below outlines our general plan for upcoming releases and key technical goals. As a community-supported project, we encourage participation through code contributions, code review, and bug reporting to help us achieve these milestones.
The following release schedule is subject to change.
The 1.8 series is our current stable release series, producing as set of releases to address security issues, bugs, and to support new kernel versions.
The 1.9 series is our current development release series, producing a rolling set of releases to facilitate access to the features being developed for the next stable release series. Currently, the 1.9.x series contains support for server-to-server communications with the rxgk Rx security class.
One long-desired feature that is expected to be in 2.0 is the rxgk Rx security class; some preliminary changes toward that feature are in gerrit waiting for review. Other desired features such as IPv6 support are listed below, but as always, are contingent on the contributions of volunteers and companies to make them happen.
Over the years, the AFS protocol has not kept up with developments in cryptography and network protocols, sticking with single-DES-grade encryption and remaining an IPv4-only service. The 2013 security release moved the long-term krb5 cell-wide keys off of single-DES, but wire encryption remains unchanged since the original AFS release.
rxgk is the long-established new security class that uses the GSSAPI for authentication and RFC 3961 cryptography for wire encryption and integrity checking. The use of the RFC 3961 framework allows for new cryptographic methods to be introduced without additional protocol changes.
Work towards rxgk has already begun, but some major pieces remain to be designed. In particular, the cache manager needs to be rearchitected to support the separation of connections to database servers and connections to fileservers; before connecting to a fileserver, the cache manager must first connect to a vlserver and learn about the fileserver. On the server side, a new vldb format must be designed to store the extended fileserver information and track which fileservers are rxgk-capable; the prdb should have mechanisms to store extended authentication names from arbitrary GSS-API clients. A procedure must be developed (and software to support it) for a seamless transition from an existing deployment to using rxgk for server-to-server communication and enable rxgk for client usage.
At present, OpenAFS represents IP addresses as uint32. This is fundamentally incompatible with IPv6, which is increasingly becoming a necessary part of the Internet ecosystem. In order to remain a fully viable solution, OpenAFS must develop support for at least clients with IPv6 addresses, but also for servers with IPv6 addresses as well.
The path to proper IPv6 support in the client is fairly clear: first, to convert all variables that hold IP addresses to be a distince type specific to IP addresses, then to convert that type to a structure containing the IPv4 address and use accessor routines for all operations with it, then adapt the accessors to be compatible with IPv6 addresses and abstract away address-family specific knowledge from the code that interacts with the accessors. On the server side, though, additional database work is needed to support storing multiple types of adderess, and RPCs developed to manage them. No commitments have been made for contributions toward this goal.