Projects
The Coda team is very small. We need your help in getting further. Below are listed a number of projects that we are looking for people to take on. Of course we are willing to discuss with you or on the list how we think the problem needs to be solved. On the whole these are projects, that we think we will not have time for in the near future, but that people have expressed interest in.
There are Kerberos patches for Coda. These allow you to gain a Coda authentication token on the basis of a Kerberos token. A number of bugs and refinements to our patches have been suggested by users. These bugs can be found on http://www.coda.cs.cmu.edu/bugs/security. Who can implement them? Most of them are basic issues that can be fixed with some simple code.
The update servers transport our configuration databases from servers to the SCM and the other way around. Currently this is done without authentication. Can someone fix this? The authentication mechanism could be made identical to that used by volutil which uses a root owned token file to authenticate to the file server.
We need someone to maintain the SparcLinux packages for Coda. Usually there is minor tinkering to be done and then it works fine again on Sparc Linux.
The Coda login program clog has a nasty little problem. When you type a wrong password, the auth2 server doesn't know you did so and continues to resend so called INIT2 packets, until a timeout occurs. The client, clog, exits immediately after the first INIT2 packet has been received, because it does know that the password was wrong.
A good fix would be to make the auth2 server detect that the password is wrong by encrypting a known cookie. If the password is wrong the INIT2 packet should not be sent with SendReliably but with XMitPacket.
Fix an interesting race condition in Venus/kernel
You can kick your client into weakly connected operation by doing cfs wd -age 5 -time 5. If this has been done, all modifications are journalled on the client, and propagated when they are 5 seconds old. Initially new files are given a local FID on the client and as part of the reintegration process, these local fids are replaced with global fids in all the data structures managed by Venus. Such changes are also installed in the kernel using the CODA_RENAME downcall. However, requests from the kernel can already be on Venus message queues before the replace fid action has told the kernel to start using the new ones. This leads to problems.
If you do a large weakly connected operation where the file created remain of importance for a while, you will see signs that this is indeed causing problems. An example is to do cvs co linux if you have a Linux CVS repository.
There are clearly many possible fixes - better synchronization of the operations being the best one. Another one would be to temporarily remember the local fids, or have a count of messages on the queue to let those go through first.