I'm just glad that after upgrading I was able to find this and find that there is an option in general settings.

In the meantime that was a lot of curse words because if you had a rogue Jira admin I am pretty sure they would not bother with some field configs or custom fields, as there are plenty other better ways to be a terrorist.

Good, it looks like sanity has prevailed, and instead of arbitrarily totally removing this functionality, you're merely disabling it by default while allowing the user to re-enable it.

Are you going to restore HTML attributes to user picker lists, or is this just going to remain another inconsistency in Jira?

In this article (https://confluence.atlassian.com/adminjiraserver0713/configuring-a-custom-field-964983512.html) is described, that it is possible to use HTML values for custom field select lists. If I do so it renders in screens but if I add a "Pie Chart" gadget to the dashboard using that custom field the HTML code is showing instead of rendering it. 

Should HTML code be used as value for custom field select lists or not?

Thanks.

gregory.hoggarth, my sincere apologies. I was performing a cleanup of some old internal tickets and inadvertently moved this one as well. That's what I get for trying to rush.

Ironically one reason to track security issues separately is because of how easy it is to accidentally conflate public and private information - which is exactly what I just did. I've re-opened this ticket and it will remain public.

Unfortunately I have no new status to share. 

Unfortunately this is now "Tracked Elsewhere" and the link provided to Ben is linking to a private internal tracker that I can't view.

So I assume that when Jira is finally updated to remove this useful piece of functionality because you bizarrely consider font tags in HTML to be a security issue, it will be fully documented in the release notes for the affected version so that I will know ahead of time before I upgrade that you are going to break my customisations?

https://hello.atlassian.net/browse/RM-11291

How is it a security issue if a Jira administrator deliberately configures their system to use HTML on field descriptions?

The only way I can see this being a security problem is if:
1. You have a rogue Jira administrator
2. Someone gains access through your network to become a Jira administrator

Both 1 and 2 are far more serious problems than just HTML tags inside field descriptions.

Or, in other words, I am making perfectly valid use of this myself, and it is in no way a security violation for my system. If you take this away in an upgrade, you will break my customisations.

Meanwhile, there is a huge amount of other missing functionality that Atlassian has not bothered to implement in over 10 years. It boggles the mind that such a minor "security" issue as this which TAKES AWAY VALUE would get preference over far many other enhancements that would ADD VALUE to your product.

gregory.hoggarth,

It is a security issue and we want to protect your and other customers data.

It has not been decided yet how we will fix the issue but we will surely try to apply the most painless solution available.

Don't worry and stay tuned. We will provide more details here once decided.

Best,
Jacek Jaroczynski
JIRA Bugmaster
[Atlassian]

Why are Atlassian scheduling to remove functionality that customers rely on, ahead of actually scheduling MISSING functionality that has been requested for OVER 10 YEARS!?!?!

I can see how searching for options with HTML in them could be tricky

oruettinger current fix will align BTF to JIRA Cloud, where it is not possible to use wiki markup in custom field option values.

Hi Atlassian,

I'm not happy with these decisions to just drop functionality without alternatives.
The same applies to drop of html support in user picker field descriptions and as i understood from a support request answer html support is being planned to be dropped from all field descriptions.

We have invested a lot in creating a more intuitive user interface by using html and now this invest is lost on update to 7.0!

We just used simple html elements as described in the previous comment and more important we are in control of that. I can't see any security problem for us here but maybe i'm just not security expert enough.
I could understand your decisions better if you were about to give more power to have options and field descriptions created by less trustable users like project administrators or user groups other than jira-administrators. But i can't see anything of this on the horizon though i'd welcome it as an overloaded jira administrator.

As it is now it's just one more frustration as we felt it when velocity support was suddenly dropped from the Atlassian JIRA Toolkit or html support was dropped from user picker field descriptions.

Regards,
Dietr

Hi gregory.hoggarth,

I understand where you are coming from, and the alternative to allow for some level of formatting control (via wiki markup rather than html) was discussed.

After some consideration, it was decided that it was best for JIRA to be in complete control of the rendering of the text to guarantee a consistent experience in the UI.

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

Instead of removing all HTML tags, why don't you just restrict the tags available?

The reason for removing this is apparently as a security reason because attacks can be executed on browsers.

Just restrict the valid HTML tags ones that cannot be used to initiate any sort of attack. I would suggest bold, underline, italic and font colours are all that is required, and these tags could not be a security risk.

Should be done together with JRA-38865