RPM package for AESCrypt?

[FreedomBen]

Hi @paulej . Long time aescrypt user here. In fact, at some point it became a critical part of my life and it's one of the first thing I have to install on newly provisioned systems.

As such I want to make an RPM package for it so it's easier to install on Fedora, CentOS, and RHEL boxes.

If I do this, will you give it your blessing (assuming it meets quality standards of course)? I can also work to get it included in the Fedora repos and becoming the package maintainer if you are agreeable to that.

Please let me know.

[paulej]

You can certainly do that, though any official channel will complain about the license terms. I hate the GNU license and refuse to license my code that way. I do use some GNU code, but none of the code I write is GNU. It's "free" as in no restrictions. So to that end, you are welcome to do whatever you want with the code I wrote.

Another issue of concern is distribution of an RPM being treated as a "munition" under export control laws. Under US federal law, crypto software requires filing notice with the government. You need to be very careful about publishing source or binaries for this reason.

The GNU / non-GNU licensing issue will likely prevent successful insertion into distribution channels. Quite frankly, I don't like to waste time trying to meet any requirements they might have, either. What I would like to do, though, is publish .rpm and .deb files directly on aescrypt.com at some point. This has been on my (very long) to-do list for a while. It just hasn't been a priority, but perhaps I need to make it one :)

BTW, I'm not sure if you're a user of the file command on Linux or not, but I got tired of doing a hex dump on .aes files to see if they were really AES Crypt files or not and what file format was used, so I created this to put into /etc/magic:

# AES Crypt File
0x00   string AES
>0x04  byte   <0x16
>>0x03 byte   0x00   AES Crypt version 0 file
>0x04  byte   0x00
>>0x03 byte   x      AES Crypt version %u file

There's my donation to the world for the day :)

[FreedomBen]

Nice! I put that in my /etc/magic. That's super handy, thank you! no more head something.aes that has characters in it that get interpreted as control sequences to the shell which results in a horked shell that has to be nuked :-D

Good points about the export control - I have no idea if that's a problem or not, but I will find out. I don't have much interest in registering with the US gov as an arms dealer lol. Did you have to do that for the binaries available at aescrypt.com? Is posting the notice about downloading from prohibited countries "good enough?" I'll check with some package maintainers and see if there is a process for this. I would imagine other crypto (which is available in the repos) has the same issues?

Re: the license, I don't think the blended license should be a problem for the official repos. There are already packages in that boat available. I think the resulting binary gets More information here: https://fedoraproject.org/wiki/Licensing:FAQ#How_should_I_handle_multiple_licensing_situations.3F

[paulej]

There's really not a registration system, per se, for "publicly available source code" (as they describe it in the law). Rather, a notification (i.e., email) has to be sent to two different addresses. The reference is here: https://www.law.cornell.edu/cfr/text/15/742.15#b

You'll see under (b)(2) the two addresses I mentioned. And, yes, I did send that notification.

If you start digging through all of this EAR crap, you can quickly get overwhelmed. So, just to be sure I was doing it correctly, I called the Department of Commerce years ago to ask about this. I spoke with a really friendly lady who said all I had to do was send those email messages given the source code is "publicly available". She also acknowledged that the Department understood there is really no control of this on the Internet.

Now, the reference above speaks about source code. Importantly, "what about object code?" As I understand, it also applies. See here: https://www.law.cornell.edu/cfr/text/15/734.3#iv_3_vi. There is a "Note" just below section (b)(3) that says: "Publicly available encryption object code “software” classified under ECCN 5D002 is not subject to the EAR when the corresponding source code meets the criteria specified in § 742.15(b) of the EAR."

As I understand, that would apply to a .rpm file, just as I interpret it to apply to the binary files I publish.

5D002: https://www.bis.doc.gov/index.php/documents/new-encryption/1652-cat-5-part-2-quick-reference-guide/file

I definitely encourage you to dig into these laws. To the best of my knowledge (and verbal confirmation from that lady from the Dept. of Commerce), I'm doing it right. And I always worry about this, since violating federal laws relating to encryption can be a big deal. It's dumb, though. These folks who wrote this mess of complex laws seem to think that no other country in the world has the technical expertise to create sophisticated encryption technology. It's seriously a bit arrogant. These laws just serve as a good example of pointless nonsense a bureaucracy can create.