# Why does Discourse block cryptographic signatures by default?
**URL:** https://meta.discourse.org/t/why-does-discourse-block-cryptographic-signatures-by-default/132912
**Category:** Feature
**Created:** [8 בנובמבר, 2019, 11:04am UTC](https://meta.discourse.org/t/why-does-discourse-block-cryptographic-signatures-by-default/132912 "2019-11-08T11:04:16Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@maltfield](https://meta.discourse.org/u/maltfield)
#### Post date: [8 בנובמבר, 2019, 11:04am UTC](https://meta.discourse.org/t/why-does-discourse-block-cryptographic-signatures-by-default/132912/1 "2019-11-08T11:04:16Z")
Discourse’s default attachment blacklist includes ‘signature.asc’ files. Why?
- [discourse/config/site\_settings.yml at e92f5e4fbf04a88d37dc5069917090abf6c07dec · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/e92f5e4fbf04a88d37dc5069917090abf6c07dec/config/site_settings.yml#L638)
It appears that, when attachment blacklists were added to Discourse on 2016-08-03, (commit e92f5e4fbf04a88d37dc5069917090abf6c07dec), the default value for the “attachment\_filename\_blacklist” variable became “smime.p7s|signature.asc” – or to block S/MIME & GPG cryptographic signature attachment files.
- [FEATURE: new email attachment blacklists site settings · discourse/discourse@e92f5e4 · GitHub](https://github.com/discourse/discourse/commit/e92f5e4fbf04a88d37dc5069917090abf6c07dec)
Cryptographic signatures are very small & harmless, yet provide a cryptographic trail for validating the authenticity of a message.
What was the logic in deciding to block them by default?
@zogstrip
---
### Author:  [@danb35](https://meta.discourse.org/u/danb35)
#### Post date: [8 בנובמבר, 2019, 1:53pm UTC](https://meta.discourse.org/t/why-does-discourse-block-cryptographic-signatures-by-default/132912/2 "2019-11-08T13:53:23Z")
> [@maltfield](#):
>
> Cryptographic signatures are very small & harmless, yet provide a cryptographic trail for validating the authenticity of a message.
By the time the email message is munged into the forum, I’d be very surprised if the signature could validate anything. Even a single space will break the signature.
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [8 בנובמבר, 2019, 1:58pm UTC](https://meta.discourse.org/t/why-does-discourse-block-cryptographic-signatures-by-default/132912/3 "2019-11-08T13:58:31Z")
It was not meant to block _cryptographic_ signatures specifically, just signatures which are often redundant.
---
### Author:  [@maltfield](https://meta.discourse.org/u/maltfield)
#### Post date: [8 בנובמבר, 2019, 2:01pm UTC](https://meta.discourse.org/t/why-does-discourse-block-cryptographic-signatures-by-default/132912/4 "2019-11-08T14:01:17Z")
Is there an example of an email client that attaches a file to an email named `signature.asc` for signatures other than _cryptographic_ signatures?
The `.asc` part signifies that it’s an ASCII-armored PGP signature, which I don’t believe is a standard outside of _cryptographic_ signature files
EDIT: And I don’t use S/MIME, but the other one (smime.p7s) seems pretty specific to _cryptographic_ signatures as well.
> signatures which are often redundant
I agree that a typical signature is usually redundant, but _cryptographic_ signatures are metadata specific to the message used for the purposes of authenticating the message’s author and providing cryptographic integrity of the message’s contents. Unlike a regular signature, a _cryptographic_ signature is _not_ redundant.