On 2007.04.19 at 11:59:39 -0700, David Schwartz wrote: > This is not nearly as simple as you might think. Are 'foo.txt' and 'Foo.txt' > the same file? What about 'directory/file.txt' and 'symlink/file.txt'? > > I don't see how you can do this without making assumptions about the > semantics of the filesystem involved. These assumptions will sometimes
I don't see why these assumptions cannot be done at compile time. There exists few different filesystem semanctics: Unix one, DOS/Windows one, VMS (versioned) one. OpenSSL already have sophisticated compile-time configuration system, which handle quite a few semantic differences between these platforms. So, it is possible to add this one. Problem is that somebody should write at least 3 different functions for different filesystem semantic, and test them thoroughly. I can contribute solution for Unix semantic which would work for all Unices I have experience with - Solaris, BSD and Linux. But I cannot be sure that it would work on all other unices supported by OpenSSL. There can be subtle API differences. Solution for Windows/DOS semantic is quite simple, because semantic of filesystem is simplier than Unix one. But I never wrote something for VMS. > Consider a filesystem that keeps version history of a file until it's > deleted. In this case, the user's request was to replace the > unencrypted version of a file with the encrypted version, keeping the > unencrypted version in history. Instead, you deleted the file's > history. This seems to be wrong idea. If user wants to override unencrypted version with encrypted, he probably don't want unencrypted version to wander around. Otherwise he'd prefer to choose different name for encrypted file. Relatively bullet-proof solution is 1. Check if input and output files are same. Check should depend on filesystem semantics and take into account such things like symlinks, or UNC paths vs mounted volumes. 2. If so, refuse to work unless special command-line switch is specified. (Thus preventing accidential destroying of input file) Switch should look like -inplace and should be specified instead of -out filename. 3. If it is specified, overwrite unencrypted data with encrypted, taking care that no unencrypted copy left in history, or left in another place of filesystem if there were multiple hard links to input file. This covers two most frequent scennarios 1. User accidentialy typed same filenames. 2. User want protect his data, making sure that access to them is not possible without knowning passphrase. This behavoir is easily understandable by user. > > There is some tension between the desire to keep the 'openssl' > command-line tool as an example of how to use the library and the > desire to make it useful for real-world tasks. I personally think the > former is considerably more important. Interactive prompting where not I think that former functionality is already lost. For me, it is simplier to write code from scratch using documentation, than study and understand code of openssl utility. It have to be refactored and commented before it could be used as examples. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
