Suggestions - permissions, timestamps, and source file naming
Hi Paul
Just discovered aescrypt. It seems to be exactly what I am looking for - a file en/decrypter which is open source and works on linux, osx and windows. Thanks very much for creating this.
I've been adapting it to create an rpm (for redhat style linux distributions) and had a couple of suggestions/observations for it:
(1) File permissions I notice that the .aes file created by encryption under linux seems to take whatever umask would give it. That may be the preferred solution - I genuinely do not know - but I would suggest that the .aes file should inherit the permissions of the file it is created from. Presumably the same should apply on decrypting.
(2) Time stamps On that subject, the encrypted version of the file, could perhaps have the same creation/modification time as the original. It could then also pass that back when it is decrypted.
(3) Name and contents of the source file It might be helpful (for packagers etc) if the linux source file adopted a more standard naming convention, and also included the man page which it also put in place. At present the source file is: aescrypt305_source.tar.gz I would suggest: aescrypt-3.0.5.tar.gz which then tar unzips to aescrypt-3.0.5/
These are all very minor points for an already good and useful piece of software. Again - thanks for creating this. Andy
Andy,
Just discovered aescrypt. It seems to be exactly what I am looking for - a file en/decrypter which is open source and works on linux, osx and windows. Thanks very much for creating this.
Well, it wasn't me alone. Several people on this list contributed in various ways :-)
I've been adapting it to create an rpm (for redhat style linux distributions) and had a couple of suggestions/observations for it:
(1) File permissions I notice that the .aes file created by encryption under linux seems to take whatever umask would give it. That may be the preferred solution - I genuinely do not know - but I would suggest that the .aes file should inherit the permissions of the file it is created from. Presumably the same should apply on decrypting.
Honestly, I can't recall having seen a program that would inherit file permissions from another file. If this were an archiver, it might make sense to do, but I'm not so sure about a tool like AES Crypt. If I wanted to preserve file permissions, I would tar files and then encrypt them. In fact, that's how I do backups ;-)
(2) Time stamps On that subject, the encrypted version of the file, could perhaps have the same creation/modification time as the original. It could then also pass that back when it is decrypted.
This is a similar kind of request that deserves a similar kind of response. AES Crypt does, in fact, create a new file. Decrypting it creates a new file, too. So, to preserve the original timesamp of the file seems disingenuous.
(3) Name and contents of the source file It might be helpful (for packagers etc) if the linux source file adopted a more standard naming convention, and also included the man page which it also put in place. At present the source file is: aescrypt305_source.tar.gz I would suggest: aescrypt-3.0.5.tar.gz which then tar unzips to aescrypt-3.0.5/
If creating an RPM, I'd definitely agree. I've not been entirely consistent with respect to naming. Once I revise the code, I might do that.
In the meantime, though, feel free to create an RPM with version numbers in the files as you'd like to see them. Is it your intent to get the file distributed with one of the major Linux versions? You'd certainly be welcome to try, if you'd like. Even though I have the source code readily available, I'd love it if the software shipped with Fedora, for example. I just don't have time to engage folks to make that happen.
Paul
Paul
Paul E. Jones wrote:
Andy,
Just discovered aescrypt. It seems to be exactly what I am looking for - a file en/decrypter which is open source and works on linux, osx and windows. Thanks very much for creating this.
Well, it wasn't me alone. Several people on this list contributed in various ways :-)
My thanks to all!
I've been adapting it to create an rpm (for redhat style linux distributions) and had a couple of suggestions/observations for it:
(1) File permissions I notice that the .aes file created by encryption under linux seems to take whatever umask would give it. That may be the preferred solution - I genuinely do not know - but I would suggest that the .aes file should inherit the permissions of the file it is created from. Presumably the same should apply on decrypting.
Honestly, I can't recall having seen a program that would inherit file permissions from another file. If this were an archiver, it might make sense to do, but I'm not so sure about a tool like AES Crypt. If I wanted to preserve file permissions, I would tar files and then encrypt them. In fact, that's how I do backups ;-)
comments below
(2) Time stamps On that subject, the encrypted version of the file, could perhaps have the same creation/modification time as the original. It could then also pass that back when it is decrypted.
This is a similar kind of request that deserves a similar kind of response. AES Crypt does, in fact, create a new file. Decrypting it creates a new file, too. So, to preserve the original timesamp of the file seems disingenuous.
Disingenuous seems a little strong! I guess my prejudice is based on other linux tools which offer similar functionality: mcrypt being a classic example (http://mcrypt.sourceforge.net/)
I just checked again, and what mcrypt does is create files (.nc) which have the same timestamp as the original and have a restricted set of permissions independent of the original files (600). On decrypting it keeps the original timestamp but the decrypted file remains as 600 independent of umask.
The rational is this I presume: though it is creating a new file that new file's content was old and dates from the time the file was last modified. In that sense this is not a new file but a secure representation of an old one. That past date still has some value after decryption which is otherwise lost. I appreciate that you could tar up the file(s) for archiving then aescript them.
Given that mcrypt was itself a drop in replacement for the old crypt command, I suspect that the behaviour I was suggesting about preserving timestamps would actually be the expected behaviour for a large number of unix/linux users. (As I stressed in the original post though - the strength of aescript is that it runs easily on multiple platforms and does not rely on too many libraries.)
(3) Name and contents of the source file It might be helpful (for packagers etc) if the linux source file adopted a more standard naming convention, and also included the man page which it also put in place. At present the source file is: aescrypt305_source.tar.gz I would suggest: aescrypt-3.0.5.tar.gz which then tar unzips to aescrypt-3.0.5/
If creating an RPM, I'd definitely agree. I've not been entirely consistent with respect to naming. Once I revise the code, I might do that.
In the meantime, though, feel free to create an RPM with version numbers in the files as you'd like to see them. Is it your intent to get the file distributed with one of the major Linux versions? You'd certainly be welcome to try, if you'd like. Even though I have the source code readily available, I'd love it if the software shipped with Fedora, for example. I just don't have time to engage folks to make that happen.
I have created an rpm - though I am no expert in this. I was not planning to lobby distributions to include it, but they determine content by the critical mass of people who want things. The best thing is to build up your user base - as you are doing. In that respect you are more than welcome to add my spec file, and rpms to your website. Rather than clog people's inboxes I will email you separately if you are interested.
Thanks again for all your efforts. Its free software and I am in your collective debt for creating it.
Andy
Paul
Andy,
Well, if there is precedent for this sort of behavior, then I guess there might be reason to do as you suggest.
We could actually implement this by adding extensions to the header of the AES Crypt file: http://www.aescrypt.com/aes_file_format.html
We could have a "FILE-TIMESTAMP" (e.g., "1295800770") and "FILE-MODE" (e.g., 0644). Introducing this metadata in the header would preserve compatibility with the current v2 file format, but it's important to note that these headers are not encrypted. If we need to secure this metadata, we would need to introduce a new version of the file format.
If you wish, I can add new extension values here: http://www.aescrypt.com/standard_extensions.html
Would we also want to preserve the user and group on Linux? Would we want to do that using numerical values or names? A concern I have with that is that it reveals user identifiable information.
In any case, I'm open to suggestions -- especially if somebody else is writing the code ;-)
Paul
-----Original Message----- From: Andy Schofield [mailto:ajs@th.ph.bham.ac.uk] Sent: Sunday, January 23, 2011 9:17 AM To: Paul E. Jones Cc: aescrypt@lists.packetizer.com Subject: Re: [aescrypt] Suggestions - permissions, timestamps, and source file naming
Paul
Paul E. Jones wrote:
Andy,
Just discovered aescrypt. It seems to be exactly what I am looking for - a file en/decrypter which is open source and works on linux, osx and windows. Thanks very much for creating this.
Well, it wasn't me alone. Several people on this list contributed in various ways :-)
My thanks to all!
I've been adapting it to create an rpm (for redhat style linux distributions) and had a couple of suggestions/observations for it:
(1) File permissions I notice that the .aes file created by encryption under linux seems to take whatever umask would give it. That may be the preferred solution - I genuinely do not know - but I would suggest that the .aes file should inherit the permissions of the file it is created from. Presumably the same should apply on decrypting.
Honestly, I can't recall having seen a program that would inherit file permissions from another file. If this were an archiver, it might make sense to do, but I'm not so sure about a tool like AES Crypt. If I wanted to preserve file permissions, I would tar files and then encrypt them. In fact, that's how I do backups ;-)
comments below
(2) Time stamps On that subject, the encrypted version of the file, could perhaps have the same creation/modification time as the original. It could then also pass that back when it is decrypted.
This is a similar kind of request that deserves a similar kind of
response.
AES Crypt does, in fact, create a new file. Decrypting it creates a new file, too. So, to preserve the original timesamp of the file seems disingenuous.
Disingenuous seems a little strong! I guess my prejudice is based on other linux tools which offer similar functionality: mcrypt being a classic example (http://mcrypt.sourceforge.net/)
I just checked again, and what mcrypt does is create files (.nc) which have the same timestamp as the original and have a restricted set of permissions independent of the original files (600). On decrypting it keeps the original timestamp but the decrypted file remains as 600 independent of umask.
The rational is this I presume: though it is creating a new file that new file's content was old and dates from the time the file was last modified. In that sense this is not a new file but a secure representation of an old one. That past date still has some value after decryption which is otherwise lost. I appreciate that you could tar up the file(s) for archiving then aescript them.
Given that mcrypt was itself a drop in replacement for the old crypt command, I suspect that the behaviour I was suggesting about preserving timestamps would actually be the expected behaviour for a large number of unix/linux users. (As I stressed in the original post though - the strength of aescript is that it runs easily on multiple platforms and does not rely on too many libraries.)
(3) Name and contents of the source file It might be helpful (for packagers etc) if the linux source file adopted a more standard naming convention, and also included the man page which it also put
in place.
At present the source file is: aescrypt305_source.tar.gz I would suggest: aescrypt-3.0.5.tar.gz which then tar unzips to aescrypt-3.0.5/
If creating an RPM, I'd definitely agree. I've not been entirely consistent with respect to naming. Once I revise the code, I might do
that.
In the meantime, though, feel free to create an RPM with version numbers in the files as you'd like to see them. Is it your intent to get the file distributed with one of the major Linux versions? You'd certainly be welcome to try, if you'd like. Even though I have the source code readily available, I'd love it if the software shipped with Fedora, for example. I just don't have time to engage folks to
make that happen.
I have created an rpm - though I am no expert in this. I was not planning to lobby distributions to include it, but they determine content by the critical mass of people who want things. The best thing is to build up your user base - as you are doing. In that respect you are more than welcome to add my spec file, and rpms to your website. Rather than clog people's inboxes I will email you separately if you are interested.
Thanks again for all your efforts. Its free software and I am in your collective debt for creating it.
Andy
Paul
participants (2)
-
Andy Schofield -
Paul E. Jones