Hi Garrett, My comments are inlines. Thanks
Regards, Bill Garrett D'Amore ???: > Frank Che wrote: > >> >> 4.2 Security concerns: >> Security becomes a concern when synchronizing files across network. >> Unison >> provides two methods for communicating between the client and the >> server: >> >> * Remote shell method: To use this method, you must have some way of >> invoking remote commands on the server from the client's command line, >> using a facility such as ssh. This method is more convenient and also >> more >> secure (especially if you use ssh). >> >> * Socket method: This method requires only that you can get TCP packets >> from the client to the server and back. >> The socket method is insecure: not only are the texts of your changes >> transmitted over the network in unprotected form, it is also possible >> for >> anyone in the network to connect to the server process and read out the >> contents of your file system! The socket method is provided only for >> expert users with specific needs; everyone else should use the remote >> shell (ssh) method. > > I presume that if there is a server here, it is not enabled by > default? Can you confirm, does this project adhere to the Secure By > Default rule? > > If there is a server, how is it administered, if at all? Yes, the project adheres to the Secure By Default rule. It's up to the user to choose which method is going to be used(ssh method, rsh method or socket method) when user executes the command unison. > > >> >> 4.3 Limitations: >> There are a few limitations in current version of Unison [2]: >> >> 4.3.1 In the interests of speed, the update detection algorithm may >> (depending >> on which OS architecture that you run Unison on) actually use an >> approximation. > > > This point has me concerned. What are the failure modes here? Will > Unison incorrectly detect clobber a file? Will it *fail* to copy a > file that has actually changed and should be updated? Heuristics here > make me queasy, especially for a system that is intended for possible > use in maintaining backups. > > How will users have this information? This limitation is well documented in the manual. As follows: Caveats and Shortcomings Here are some things to be careful of when using Unison. * In the interests of speed, the update detection algorithm may (depending on which OS architecture that you run Unison on) actually use an approximation to the definition given in the What is an Update? section. In particular, the Unix implementation does not compare the actual contents of files to their previous contents, but simply looks at each file's inode number and modtime; if neither of these have changed, then it concludes that the file has not been changed. Under normal circumstances, this approximation is safe, in the sense that it may sometimes detect "false updates" will never miss a real one. However, it is possible to fool it, for example by using retouch to change a file's modtime back to a time in the past. > >> >> 4.3.2 When synchronize between a single-user file system and a shared >> Unix >> server, by default, Unison will synchronize permissions verbatim, >> which may >> leave group-writable files on the server that could be written over >> by a lot of >> people. >> >> 4.3.3 The graphical user interface of Unison is single-threaded. > > > The above two aren't really areas of concern, IMO. > >> >> 4.3.4 Unison does not understand hard links. > > > That's pretty unfortunate. I guess the necessary consequence of this > is that Unison my dramatically increase the bandwidth needs and > storage needs on the remote side. Imagine synchronizing a 4G ISO > image, which also has hardlinks to other names -- instead of > transferring and storing one 4G image, you are transferring and > storing n * 4G. > > Can this result in previous hard links being busted? Will updates > copied from one file on a remote node potentially clobber a > hard-linked clone elsewhere? (Put another way, if a file A is > hardlinked to file B, and a remote copy of A called C is updated, will > the synchronization of A from C by Unison cause any change to B?) The test result is, the synchronization of A from C doesn't cause any change to B. And the hard link between A and B was destroyed. This limitation is also documented in Caveats and Shortcomings section of the manual. > >> >> 4.3.5 Renaming directories that containing "ignore"d files may result >> in loss >> of data. > > > That's a potentially bad failing. Unintended loss of data is never a > good failure mode. > > It seems (to me at least) that this tool can easily be used in ways > which are potentially destructive. (How destructive depends on the > answers to the above questions.) While I understand that such a tool > can be useful, it has some pretty significant caveats. This limitation is documented in the Caveats and Shortcomings section of the manual. > > > >> >> 4.5 Interfaces >> >> 4.5.1 Imported Interfaces >> +------------------------------------------------------------------+ >> | NAME | STABILITY LABEL | DESCRIPTION | >> +-----------------------+-----------------+------------------------+ >> | libsocket | Committed | PSARC/1995/014 | >> +------------------------------------------------------------------+ >> >> 4.5.2 Exported Interfaces >> +------------------------------------------------------------------+ >> | NAME | PROPOSED | DESCRIPTION | >> | | STABILITY LABEL | | >> +-----------------------+-----------------+------------------------+ >> | SUNWunison | Uncommitted | Unison package | >> |-----------------------+-----------------+------------------------| >> | /usr/bin/unison | Committed | Unison executable | >> |-----------------------+-----------------+------------------------| >> | ~/.unison/default.prf | Uncommitted | Unison default profile | >> +------------------------------------------------------------------+ > > > I probably shouldn't repeat this, but I am again concerned about > Committed for an application that seems to have a somewhat limited > audience and may itself no longer be actively developed or maintained. > (See http://www.cis.upenn.edu/~bcpierce/unison/status.html for that > status information.) This is all the more so given the above > limitations, which it now seems are unlikely to be resolved given the > development status. > > The more I think about it, the more I'd like to see ARC have some > oversight about how things like this are delivered -- this seems > ideally suited for an external repo -- readily accessible to users > that want it, but not installed by default. > > Certainly, the value of the "stability" of the path name of an > executable seems significantly reduced without some idea of how and > whether it will be delivered by default. > > -- Garrett > >> >> 4.6 Release binding >> Release binding requested: patch/micro. >> >> >> 6. Resources and Schedule >> 6.4 Steering Committee Requested Information >> 6.4.1 Consolidation C-team Name: SFW >> 6.5 ARC review type: Fast Track >> 6.6 ARC exposure: open >> >> >> Footnotes: >> ---------- >> [1] http://www.cis.upenn.edu/~bcpierce/unison >> [2] See man page of Unison for more details. >> >> >
