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.