You've come to this page because you've said something similar to the following:
Self-decrypting files (a.k.a. self-decrypting archives, or SDAs) are cool.
This is the Frequently Given Answer to such statements.
Self-decrypting files are not cool at all. As far as security goes self-decrypting files are in fact a very a bad idea. They undermine the very reasons that one is using encryption in the first place. If you think about why one encrypts files in the first place, and what parts of an encryption/decryption system need to be trustworthy, you should see why self-decrypting files are yet another Half-Baked Idea from those industrious chaps in the Half-Baked Ideas Brigade.
Self-decrypting files are bad for portability reasons, as well. Self-decrypting files only work if the sender and recipient have computers with the same CPU architecture and the same operating system. They are also not future-proof.
(History teaches a lesson here. Look at all of the self-extracting archives created for MS/PC-DOS systems in the 1980s and 1990s — which people then thought were "nifty" and "cool", too — and think about how many such DOS softwares now cannot run on modern PCs because they only work on old versions of MS/PC-DOS, or only work on MS/PC-DOS, or cannot cope with large volume sizes, or don't work right on modern CPUs, or … )
Don't use self-decrypting files. If someone sends a self-decrypting file to you, ask for an file that can be decrypted with an ordinary standalone decryption tool, instead. If you want to send someone an encrypted file, and they don't have the decryption tool, then either
In an encryption/decryption system, the tool used to perform decryption must be trusted by the recipient. Self-decrypting files do not provide that trust, because any man-in-the-middle attacker who provides a fake encrypted file to the recipient, pretending to be the sender, gets to provide the decryption tool, that processes the file on the recipient's behalf, as well.
Self-decrypting files are thus a man-in-the-middle attacker's dream come true. The attacker can make the decryption tool do whatever xe wants. Always yielding a positive response, and assuring the recipient that the file created by the man-in-the-middle was digitally signed/created by the sender, is in fact not even the most major of the recipient's problems as far as man-in-the-middle attacks are concerned.
Recipients who have been sent self-decrypting files should bear in mind three important points:
You, the recipient, are being asked to run a program that could potentially have been compromised by a third party attacker. You have no guarantee that the program that you are using, to check that what you have received was in fact encrypted by the sender, was itself sent by the sender. If you are using digital signatures to check the the files that you receive really came from the sender and no-one else, you should be requiring that the sender also sign the decryption program, too. That program is a file that you really need to be assured came from someone that you trust, too, after all. And if you are requiring that the decryption program be signed, then you must already have a decryption tool and don't need self-decrypting files in the first place.
You, the recipient, are being asked to run a program that you just downloaded from somewhere without using a secure connection, or that you received in an electronic mail message that could have been sent by anyone. Experience with computer worms should teach that this is a terrible idea. You have no assurance that the program that you are about to run even is a decryption tool in the first place. For all you know, you are about to run a program that will overwrite every third file on your disc with the string "Hello, Billy!".
Senders who belong to the Half-Baked Ideas Brigade may at this point propose using secure HTTP, or digitally signed electronic mail, to send the self-decrypting file to recipients. To them, the response is: "Stop! Think! Wasn't the very reason that you are using self-decrypting files in the first place the fact that the recipients didn't have decryption tools already? To employ secure HTTP or digitally signed electronic mail, they must already have some decryption capabilities. If they haven't, they cannot use secure HTTP or digitally signed electronic mail. If they have, they don't need secure HTTP or digitally signed electronic mail because they don't need a self-decrypting file."
You, the recipient, have just given your secret password (either the shared secret that you shared with only the sender, or the secret password that you use to unlock your private keyring) to a program that, for all you know, could have been a trojan horse supplied by a third party attacker. What if the attacker has chosen to make the trojan horse program do everything that a real decryption program does, including decrypt the sender's original encrypted file properly, but in addition send a copy of your password to the attacker behind the scenes? Now the attacker knows your password. If it was a shared secret that you shared with the sender, all of your communications with that sender are compromised. If it was the secret password for your private keyring, all of your encrypted data and communications with everyone are compromised.
People who publish decryption tools expend effort to ensure that recipients can trust the actual decryption tools themselves before running them. (Witness the integrity check instructions for GNU Privacy Guard (GPG), for example.) There are reasons for this.