(Illustration by Gaich Muramatsu)
On Tue, Apr 19, 2016 at 10:13:06AM +0200, u-myfx_at_aetey.se wrote: > > The official Coda git repository is now at > > > > https://github.com/cmusatyalab/coda > > > > There is no new release yet, I just made the push to finish the conversion > > last week and want to make sure there are not any more unapplied patches > > floating around, and then I have to dust off/rewrite whatever I used to > > use to make releases. > > For the record, there exists our yet-unpublished Aetey/Chalmers branch, > differing quite a bit from 6.9.5, with > > - the s.k. modular clog included, with proper integration with Kerberos > and support for multiple authentication authorities (this appeared > at CMU long ago but never made it to upstream) > - server IP addresses can be changed without disrupting client > operation and without client-side administration, removing the afs-derived > "static server IP" contraint > - clents can handle servers running on non-standard ports (as a result > e.g. more than one server can be put behind the same NAT) > - a bunch of small fixes and tweaks I've seen the modular clog a long time ago and I remember it was not in a state to be easily merged, added a bunch of complexity and additional configuration for what I thought were not typical cases. The few comments I remember were, - the clog token file format was/is not portable across platforms and needed to be cleaned up so that different endianess systems could also read the tokens that were used, not everything is x86. - there was some sort of configuration daemon serving up configuration data for the authentication from a tcp port which introduces a whole slew of unevaluated security concerns. Since it is http how is the configuration secured from MitM attacks, can someone replace authentication with an auth-null forcing the clients to suddenly send out cleartext passwords, etc. And if it is secured (HMAC?), how do client know how to properly vet the signature, etc. As far as the other changes, I haven't seen any of them but I can still throw out some unsollicited comments. Allowing server IP addresses to change without client-side intervention has to introduce some new level of indirection above the IP layer and the most obvious one is to refer to servers using their DNS names. This works nicely with the 'new' RPC2 call I added almost 10 years ago. https://github.com/cmusatyalab/coda/commit/86d97f6db3ac13d6d83f47636e23891f9380f537 The response to that RPC call even includes the port the server is running at. The only part that has not been implemented is the client side and it only got stalled because the available async DNS libraries were either not LWP compatible, or had a non-GPL compatible license. Synchronous DNS blocks the complete client process causing various kinds of connectivity/reliability issues, so I am interested to see how you solved that part of the problem. > It remains compatible to servers and clients built from upstream code, > modulo the new features which upstream does not yet support. > > The best would be to merge the changes upstream. They are vital for > usability. Unless you have managed to fix some horrible reintegration/resolution conflict introducting bug, I respectfully disagree with the 'vital' part of that statement. But merging upstream is for many things, especially bug fixes, always a good idea. > What is the expected workflow for submitting and reviewing patches? Well, github has the concept of pull requests. The best method seems to be to have small, independent, single purpose changes on 'feature branches' that can be easily read, reviewed and merged. Any single large diff that touches many different parts would inevitably take a longer time and may require several roundtrips as issues are found and addressed. Right now I'm mostly concerned with cleaning things up and addressing some bugs and possible security issues I believe I have identified. Anything that removes lines of code, and/or reduces overall complexity will be much easier to merge because it reduces the amount of cleanup necessary. Jan ps. About the 'as yet-unpublished' part of your comment, I do hope you are adhering to the GPL license, as you distribute binaries of Coda with extensive changes you are expected to make the corresponding source available. In fact as a company, you would be expected to make source available even if there are no extensive changes.Received on 2016-04-20 11:50:13