> I have been using openssl for some personal home-use encryption, and > recently overwrote an input file while using openssl bf accidentally > because bash's autocompletion put in the input file's name when I > started typing the same name (minus bf at the end) for the output and I > carelessly hit enter. > > For me it was not a big issue since those files were recoverable from > elsewhere but there are probably people using openssl for more important > things and they might have a serious problem if such a thing happened. > > So I request that openssl bf and other such openssl commands must check > whether the input and output filenames are same and in such case give > the user a warning and ask whether the user wants the output file to > have the same name by deleting the input file after processing. > > If yes, then use a temporary file name till processing is done and then > delete the input file and do something like mv tempfile origfile. > > If no, then abort. > > Since this is not a technical problem but an interface feature request I > did not include the make report output etc (since I am using a pre-built > openssl from my distro).
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 be right and sometimes be wrong. With the proposed change, in some cases you'll be deleting a file that the user did not ask you to delete (or doing nothing at all), but you won't be able to do what the user specifically asked you to do. 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. 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 expected is also not a particularly good idea. (Though these arguments are, I think, weaker in this particular case where the requested behavior is most likely to do nothing even remotely useful.) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
