How do I stop/modify emails on security issues?

[Michael de Raadt]

Hi.

When a user reports a security issue, an email is sent back to them in plain text. All subsequent activity on the issue is also reported by email to all watchers and paticipants.

As it's not really feasible to encrypt such emails, I have been looking for a way to stop notifications for issues that are reported as security issues. Beyond creating a separate project with its own notification scheme, does anyone have a suggestion for how emails could be stopped based on the security level field?

Alternately, is there a way to control what information is sent in emails and controlling that depending on the security level?

Michael.

[Michael de Raadt · Accepted solution]

I've raised an issue suggesting that the content of notifications for issues with a security level set should be controlled.

[Michael de Raadt]

The solution we eventually adopted was to hack the email templates used by Jira. In the templates, there is potential to distinguish security issues and act selectively.

#if ($issue.securityLevel)
        output a simplified version masking details
    #else
        output the normal thing
    #end

I've reported this issue as a bug to Jira JRA-37581, but Jira doesn't think this is something worth changing. Hopefully they'll change their mind.

It's good to know that we now have a more secure instance of Jira than Jira themselves.

[Norman Abramovitz]

You could create a fake smtp server(maybe a relay service) that could scan the email and filter (drop) the email messages before forwarding them on. The smtp relay service could run on the same machine as Jira. The relay service could interface with a secure smtp service if you want to deliver the email securely.

[Todd]

I found a feature request that looks like it would do something similar to what you are looking for. I suggest voting for it if it will fit your needs.

https://jira.atlassian.com/browse/JRA-4742

[Michael de Raadt]

Thanks, Todd.

[Nic Brough -Adaptavist-]

You mention the security level field - Jira will only send email to people who can see an issue, so if you're using security levels, that could stop the emails to people who shouldn't see them.

(Unless you've configured something like the JETI plugin which allows you to leak information to users who couldn't normally see it)

[Michael de Raadt]

Hi, Nic.

It is true that Jira limits access to certain people, but our problem is that it still sends emails to those people in plain text, including the reported details of the problem, which is insecure.

[Nic Brough -Adaptavist-]

Then you need to find out what you have configured that is letting it leak this information and turn it off.

If a user cannot see an issue, Jira will not send email to them, unless you've bypassed the security on emails. It's usually a plugin like JETI or a script-runner function to send extra emails or a post-function to do the same. Or, you might have set up a dummy user with a group email address.

[Michael de Raadt]

I don't think you read what I wrote, Nic.

Emails are not being sent to people who should not be receiving them. That is not the problem.

The problem is how the emails are being sent. I can find no way of configuring Jira to stop sending emails, or to modify the content of emails, when the issue is a security issue. So the details of security issues are being sent by email, unencrypted and open to interception.

[Nic Brough -Adaptavist-]

Mmm, it was spectacularly unclear. You've never defined what a "security issue" is for a start. I was assuming you needed to hide them properly from users and had implemented that.

Now I understand that you've got an issue type that you don't want to send email for, but your users should still be able to see it in Jira.

Simple answer - move them to a project with a notification scheme that says "don't send email"

I don't think there's another way to supress email directly without hiding the issues, which means people won't see them in the ui either.

[Michael de Raadt]

I've never been accused of being "spectacularly unclear" before. We could go around in circles like this for a while, if you like.

We are using a pretty ordinary security scheme with a level field that distinguishes security issues.

I'd prefer not to split our project as it's rather large with many people involved. I had considered that, but it seems there should be alternatives.