Two bugs & a smaller glitch

[wolfy]

There are two VERY annoying things that bug me in aescrypt:

1. The decryption mode does NOT check if the filename has any (!) extension at all, let alone the extension .aes
Thus, if the file is renamed and then attempted to be decrypted, the last four characters are removed IN ANY CASE, even if the filename is shorter than four characters!
This results in destruction of the filename if it is longer than 4 chars but has no extension, and - even worse - in a complete crash (!!!) (i.e. segmentation fault on Linux and a crash message on Windows) if the name length is less or equal 4 characters!
As the encrypted file is disappears anyway, why not simply keep the original name if there is no extension?
This would be the sensible way to do (and I have a script which does exactly that to work around this shortcoming)

2. The windows version can't handle forward slashes (i.e. file URLs) in the -o option, which is a problem when using it in cygwin - one can't specify any absolute or relative path other than a simple filename (i.e. one in the same directory), which somehow beats the purpose of the -o option.


* Some other glitch I noticed:

In cygwin aescrypt apparently can't read the user input from the keyboard when entering a password - passwords only work when specifying them with -p

There was another small glitch, but I forgot what it was... I might be back

[paulej]

I verified the issue with filenames less than 4 characters. That ought not happen. I thought there was logic to address that, but as I think about it, what would be an appropriate name? Maybe the program should just exit if a suitable filename wasn't entered via the -o flag. We can't simply use the same filename, because aescrypt doesn't remove an original file. That is, it doesn't simply disappear.

If the windows code doesn't handle forward slashes, then that's a Windows problem. I thought it worked, but aescrypt isn't responsible for finding files on disk. It takes the filename as given and passes it to fopen(). Thus, it's either Windows or cygwin failing here. I won't try to fix that, as that's not a bug.

[wolfy]

Hi paulej,

thanks for your answer.

I verified the issue with filenames less than 4 characters. That ought not happen. I thought there was logic to address that, but as I think about it, what would be an appropriate name? Maybe the program should just exit if a suitable filename wasn't entered via the -o flag. We can't simply use the same filename, because aescrypt doesn't remove an original file. That is, it doesn't simply disappear.

If the name does not have an extension or is shorter than 4 characters, simply replace the aes-file (recognized by the magic bytes at the beginning of the file presumably) with the decrypted file with the same name.
A copy of the decrypted file WITH the correct extension ".aes" could automatically be created. (this behaviour could be configured, i.e. switched off, with a command line option)

If this is not feasibly, the program should at least exit *gracefully* with a meaningful error message and dedicated error code (instead of either crashing for filename length < 4 or reporting "Error opening output file : No such file or directory" for filename length = 4, because the resulting filename is empty!) so that some sort of renaming prior to decryption can take place in a calling script.

And if you INSIST on an extension which you like to cut in any case, you should perhaps enforce the default one (and let that behaviour also be overriden by a command line option as well).

If the windows code doesn't handle forward slashes, then that's a Windows problem. I thought it worked, but aescrypt isn't responsible for finding files on disk. It takes the filename as given and passes it to fopen(). Thus, it's either Windows or cygwin failing here. I won't try to fix that, as that's not a bug.

Hm. I see. I don't see why it does not work though. I'll have to look into fopen() to see how path separation characters are treated there.
Are you shure that you are using the latest Win-API? The mentioned smaller glitch (aescrypt does not read password from STDIN/keyboard in Cygwin!) seems to be related.

Speaking of error codes (that was the thing I forgot in my first post):

I did not find any documentation on the exit codes, and people are obviously stumped by this, see e.g.:
http://forums.packetizer.com/viewtopic.php?f=72&t=523

I found out by trial and error that code 127 means "(destination) file or path could not be opened (for whatever reason...)" (in Cygwin, when stumbling over the path separator issue), but the poster of the above topic apparently did not know what "127" means, or otherwise he would've realized earlier that it was a path problem, which he did later...