Return to Answer

This is only a part of an answer, because forest already covered a lot of ground.

It's the outputting untrusted text that I am most worried about.

You can easily avoid handling untrusted text in the terminal. First, in your mail client, store the encrypted gpg block in a file, for example /tmp/encrypted_message.txt

Then, in the terminal, run

$ gpg ...options... /tmp/encrypted_message.txt -d -o /tmp/decrypted_message.txt 

So now you have the decrypted message in /tmp/decrypted_message.txt without ever having untrusted data touch the terminal/shell. Open the decrypted file in any application you trust to display it, or e-mail it back to yourself (since you already use that to display untrusted text whenever you receive an unsolicited message).

You should worry about other things

Running shell commands hidden in user input is actually a likely attack vector, because lots and lots of systems are vulnerable to this, so from the attacker's view it pays to develop the necessary evil payloads, and from your point of view it's clever to remove the shell from your pipeline when handling user input whenever you can. But by storing the encrypted untrusted input in a file and having gnupg output the decrypted text into another file, you've already eliminated all contact between untrusted data and the shell.

Instead, you should now worry about flaws in the rest of your pipeline's applications. gpg could contain a flaw that let an attacker run arbitrary machine code (usually code that gives an attacker a shell) on your computer. But gpg features in far less pipelines than, say, a webbrowser or a mail client, so It seems unlikely an attacker would pick GnuPG to look for flaws that allowed him to run shellcode, instead of the much more often used webbrowsers and mail clients, (unless he targets GnuPG users or you specifically, of course - someone might be targeting GnuPG users, but there are so many high-exposure software packages that seem like better targets that I think you'd primarily have to worry about someone who actually targets you or your website, individually).

Airgapping to read messages users of your website send to you sounds way over-cautious to me unless you're running the next Silk Road and are afraid US law enforcement is after you, in which case I could understand why you worry. But if you do want to isolate gpg, you can use software such as firejail. This means that an attacker who has found a flaw in GnuPG that allows him to run arbitrary code will also have to find a flaw in the linux kernel before he can escape from the jail into your actual system and do more damage.

(Edit: Changed the answer to reflect the discussion in the comments/chat)

This is only a part of an answer, because forest already covered a lot of ground.

It's the outputting untrusted text that I am most worried about.

You can easily avoid handling untrusted text in the terminal. First, in your mail client, store the encrypted gpg block in a file, for example /tmp/encrypted_message.txt

Then, in the terminal, run

$ gpg ... -o /tmp/decrypted_message.txt ... 

So now you have the decrypted message in /tmp/decrypted_message.txt without ever having untrusted data touch the terminal/shell. Open the decrypted file in any application you trust to display it, or e-mail it back to yourself (since you already use that to display untrusted text whenever you receive an unsolicited message, so you're not increasing the attack surface).

You should worry about other things

Running shell commands hidden in user input is actually a likely attack vector, because lots and lots of systems are vulnerable to this, so from the attacker's view it pays to develop the necessary evil payloads, and from your point of view it's clever to remove the shell from your pipeline when handling user input whenever you can. But by storing the encrypted untrusted input in a file and having gnupg output the decrypted text into another file, you've already eliminated all contact between untrusted data and the shell.

Instead, you should now worry about flaws in the rest of your pipeline's applications. gpg could contain a flaw that let an attacker run arbitrary machine code (usually code that gives an attacker a shell) on your computer. But gpg features in far less pipelines than, say, a webbrowser or a mail client, so It seems unlikely an attacker would pick GnuPG to look for flaws that allowed him to run shellcode, instead of the much more often used webbrowsers and mail clients, (unless he targets GnuPG users or you specifically, of course - someone might be targeting GnuPG users, but there are so many high-exposure software packages that seem like better targets that I think you'd primarily have to worry about someone who actually targets you or your website, individually).

Airgapping to read messages users of your website send to you sounds way over-cautious to me unless you're running the next Silk Road and are afraid US law enforcement is after you, in which case I could understand why you worry. But if you do want to isolate gpg, you can use software such as firejail. This means that an attacker who has found a flaw in GnuPG that allows him to run arbitrary code will also have to find a flaw in the linux kernel before he can escape from the jail into your actual system and do more damage.

(Edit: Changed the answer to reflect the discussion in the comments/chat)

This is only a part of an answer, because forest already covered a lot of ground.

It's the outputting untrusted text that I am most worried about.

You can easily avoid handling untrusted text in the terminal. First, in your mail client, store the encrypted gpg block in a file, for example /tmp/encrypted_message.txt

Then, in the terminal, run

$ gpg ...... -o /tmp/decrypted_message.txt 

So now you have the decrypted message in /tmp/decrypted_message.txt without ever having it touch the terminal. Open the decrypted file in any application you trust to display it, or e-mail it back to yourself (since you already use that to display untrusted text whenever you receive an unsolicited message).

You should worry about other things

I'd just like to point out that if you're worrying about executing shell commands by mistake, then you're pipleline to handle these vulnerability reports is seriously flawed.

First, @symcbeans comment in the question is relevant: Why do you handle decryption manually in a shell? If you get rid of the shell, you get rid of the possibility of executing shell commands hidden in the user input.

Getting rid of the shell is easy. Use any scripting language that supports running external processes, and make sure you set the arguments correctly so as not to call a shell.

In Python, you can do this using the subprocess module and making sure you set the shell=False argument when calling the external process. Other scripting languages provide equivalent functionality. Voilà - you no longer have to be afraid of accidentally running shell commands.

Running shell commands hidden in user input is actually a likely attack vector, because lots and lots of systems are vulnerable to this, so from the attacker's view it pays to develop the necessary evil payloads, and from your point of view it's clever to remove the shell from your pipeline when handling user input whenever you can.

Second, worry about flaws in the rest of your pipeline's applications. GnuPG features in far less pipelines than, say, a webbrowser or a mail client, so It seems unlikely an attacker would pick GnuPG to look for flaws that allowed him to run shellcode, instead of the much more often used webbrowsers and mail clients, (unless he targets GnuPG users or you specifically, of course - someone might be targeting GnuPG users, but there are so many high-exposure software packages that seem like better targets that I think you'd primarily have to worry about someone who actually targets you or your website, individually).

Airgapping to read messages users of your website send to you sounds way over-cautious to me unless you're running the next Silk Road and are afraid US law enforcement is after you, in which case I could understand why you worry.

This is only a part of an answer, because forest already covered a lot of ground.

It's the outputting untrusted text that I am most worried about.

You can easily avoid handling untrusted text in the terminal. First, in your mail client, store the encrypted gpg block in a file, for example /tmp/encrypted_message.txt

Then, in the terminal, run

$ gpg ...options... /tmp/encrypted_message.txt -d -o /tmp/decrypted_message.txt 

So now you have the decrypted message in /tmp/decrypted_message.txt without ever having untrusted data touch the terminal/shell. Open the decrypted file in any application you trust to display it, or e-mail it back to yourself (since you already use that to display untrusted text whenever you receive an unsolicited message).

You should worry about other things

Running shell commands hidden in user input is actually a likely attack vector, because lots and lots of systems are vulnerable to this, so from the attacker's view it pays to develop the necessary evil payloads, and from your point of view it's clever to remove the shell from your pipeline when handling user input whenever you can. But by storing the encrypted untrusted input in a file and having gnupg output the decrypted text into another file, you've already eliminated all contact between untrusted data and the shell.

Instead, you should now worry about flaws in the rest of your pipeline's applications. gpg could contain a flaw that let an attacker run arbitrary machine code (usually code that gives an attacker a shell) on your computer. But gpg features in far less pipelines than, say, a webbrowser or a mail client, so It seems unlikely an attacker would pick GnuPG to look for flaws that allowed him to run shellcode, instead of the much more often used webbrowsers and mail clients, (unless he targets GnuPG users or you specifically, of course - someone might be targeting GnuPG users, but there are so many high-exposure software packages that seem like better targets that I think you'd primarily have to worry about someone who actually targets you or your website, individually).

Airgapping to read messages users of your website send to you sounds way over-cautious to me unless you're running the next Silk Road and are afraid US law enforcement is after you, in which case I could understand why you worry. But if you do want to isolate gpg, you can use software such as firejail. This means that an attacker who has found a flaw in GnuPG that allows him to run arbitrary code will also have to find a flaw in the linux kernel before he can escape from the jail into your actual system and do more damage.

(Edit: Changed the answer to reflect the discussion in the comments/chat)

This is only a part of an answer, because forest already covered a lot of ground.

I'd just like to point out that if you're worrying about executing shell commands by mistake, then you're pipleline to handle these vulnerability reports is seriously flawed.

@symcbeans comment in the question is relevant: Why do you handle decryption manually in a shell? If you get rid of the shell, you get rid of the possibility of executing shell commands hidden in the user input.

Getting rid of the shell is easy. Use any scripting language that supports running external processes, and make sure you set the arguments correctly so as not to call a shell.

In Python, you can do this using the subprocess module and making sure you set the shell=False argument when calling the external process. Other scripting languages provide equivalent functionality. Voilà - you no longer have to be afraid of accidentally running shell commands.

Running shell commands hidden in user input is actually a likely attack vector, because lots and lots of systems are vulnerable to this, so from the attacker's view it pays to develop the necessary evil payloads, and from your point of view it's clever to remove the shell from your pipeline when handling user input whenever you can.

By comparison, GnuPG features in far less pipelines, so directly attacking a buffer overflow or similar flaw that would allow an attacker to run binary shellcode is much less likely (unless he targets GnuPG users or you specifically, of course - someone might be targeting GnuPG users, but there are so many high-exposure software packages that seem like better targets that I think you'd primarily have to worry about someone who actually targets you or your website, individually).

Airgapping to read messages users of your website send to you sounds way over-cautious to me unless you're running the next Silk Road and are afraid US law enforcement is after you, in which case I could understand why you worry.

This is only a part of an answer, because forest already covered a lot of ground.

It's the outputting untrusted text that I am most worried about.

You can easily avoid handling untrusted text in the terminal. First, in your mail client, store the encrypted gpg block in a file, for example /tmp/encrypted_message.txt

Then, in the terminal, run

$ gpg ...... -o /tmp/decrypted_message.txt 

So now you have the decrypted message in /tmp/decrypted_message.txt without ever having it touch the terminal. Open the decrypted file in any application you trust to display it, or e-mail it back to yourself (since you already use that to display untrusted text whenever you receive an unsolicited message).

You should worry about other things

I'd just like to point out that if you're worrying about executing shell commands by mistake, then you're pipleline to handle these vulnerability reports is seriously flawed.

First, @symcbeans comment in the question is relevant: Why do you handle decryption manually in a shell? If you get rid of the shell, you get rid of the possibility of executing shell commands hidden in the user input.

Getting rid of the shell is easy. Use any scripting language that supports running external processes, and make sure you set the arguments correctly so as not to call a shell.

In Python, you can do this using the subprocess module and making sure you set the shell=False argument when calling the external process. Other scripting languages provide equivalent functionality. Voilà - you no longer have to be afraid of accidentally running shell commands.

Running shell commands hidden in user input is actually a likely attack vector, because lots and lots of systems are vulnerable to this, so from the attacker's view it pays to develop the necessary evil payloads, and from your point of view it's clever to remove the shell from your pipeline when handling user input whenever you can.

Second, worry about flaws in the rest of your pipeline's applications. GnuPG features in far less pipelines than, say, a webbrowser or a mail client, so It seems unlikely an attacker would pick GnuPG to look for flaws that allowed him to run shellcode, instead of the much more often used webbrowsers and mail clients, (unless he targets GnuPG users or you specifically, of course - someone might be targeting GnuPG users, but there are so many high-exposure software packages that seem like better targets that I think you'd primarily have to worry about someone who actually targets you or your website, individually).

Airgapping to read messages users of your website send to you sounds way over-cautious to me unless you're running the next Silk Road and are afraid US law enforcement is after you, in which case I could understand why you worry.