Claim the rx epoch/cid generation task.
[openafs-wiki.git] / RXGKToDo.mdwn
index dce9f0f..c9f67ae 100644 (file)
@@ -15,5 +15,5 @@ If you wish to work on any of these items, please note your interest by adding y
 * Review the existing rxgk code that kaduk will be posting to gerrit
 * Review the existing pthread-bos code on gerrit -- bos is a nice simple standalone protocol to play with rxgk-ifying, but it is only possible for the pthreaded version.
 * Decide whether the bosserver should use an ephemeral token-encrypting key.  There are no long-lived connections to the bosserver and this would save on the hassle of putting another key on disk, but it makes localauth more complicated.  Absent a scheme to print initiator credentials from given acceptor credentials (could be done for krb5 with a sort of kimpersonate), we probably have to do a real GSS negotiation, which depends on the network and everything being configured properly.
-* Move rx epoch and cid generation into the core rx code (out of rxkad).  This will require some thought to seed the rfc3961 crypto random generator in the kernel on platforms which do not already implement in-kernel randomness (maybe just HPUX or something like that?).  An attempt at this is at https://github.com/kaduk/openafs/commits/epoch but that branch has been overtaken by events in terms of rfc3961 support, I (kaduk) believe.
+* Move rx epoch and cid generation into the core rx code (out of rxkad).  This will require some thought to seed the rfc3961 crypto random generator in the kernel on platforms which do not already implement in-kernel randomness (maybe just HPUX or something like that?).  An attempt at this is at https://github.com/kaduk/openafs/commits/epoch but that branch has been overtaken by events in terms of rfc3961 support, I (kaduk) believe.  Update: kaduk will try picking this up again.
 * Teach asetkey to produce a random key in the KeyFileExt to be used as the cell-wide token-encrypting key.