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? > > 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? > > 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?) > > 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. > > 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. > >
