Why does Discourse block cryptographic signatures by default?

Feature
1

Discourse’s default attachment blacklist includes ‘signature.asc’ files. Why?

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.

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

2

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.

3 Likes
3

It was not meant to block cryptographic signatures specifically, just signatures which are often redundant.

3 Likes
4

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.