View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0030791||mantisbt||security||public||2022-07-22 16:14||2022-08-08 11:03|
|Summary||0030791: Allow adding relation type noopener/noreferrer to outgoing links|
There are a lot of security related topics around the
|Steps To Reproduce|
|Tags||No tags attached.|
Sounds like good practice indeed, but why specify both ? noreferrer implies noopener so it's redundant; I do not see in what way preventing the referer header is increasing security. I would think noopener is sufficient to cover the vulnerability.
Yea, your right. Read about it, but can't remember where and can not find it right now, but the point was, that the different browser implement it differently, and so the recommendation was "use both".
I am not really sure about it, but will try.
The referrer expose the super-secret-internal URL of the mantis. :-)
Considering we are no longer supporting IE, and require a "recent" browser, I think it's safe to only use noopener.
I guess your use case is MantisBT on an company network, and don't want the URL to be sent to external sites, right ?
@dregad not sure you are aware (I was not) that the "URL Processing" setting does not apply if "Markdown Processing" is activated.
Cool, is this also covering the
Is there the need to populate the new attribute to parsdowns
because the attribute is not in defaults at parsedowns site 
Yes. Not mine but well known installations.
The escaping of the two links in my previous looks broken?
does not match the intented output?
No, not "populate to parsedown", the attribute is added after the block is created by Parsdown.
No idea when
I must have known it at some point, i.e. when I was fixing some bugs on custom MantisMarkdown class, like 5 years ago... But I forgot ;-)
Nope, based on the above and as you found out, it is not. On my dev box yesterday, I was testing with Markdown disabled.
Known, long-standing issue, see 0024628
I am not sure off-hand where the change should be made. It's been a long time since I've looked at Parsedown and it's a complex beast.
So, after analysis:
It's worth mentioning that when Markdown is enabled, such URLs are always converted to links, regardless of MantisCoreFormatting URL Processing setting's value. IMO this is a bug, they should only be processed if it is ON.
There is also inlineUrlTag(), which should be called when processing
I have a work-in-progress branch on my dev box, that looks promising but needs some more testing before I can push it to the PR. It's getting late so I'll do that maybe tomorrow night.
Yes, i think your right, the processing is mixing up things, what is causing the most of all the topics around Markdown.
I'm new to the source code site of Mantis and just figuring out how the things work. So there is a high probability that i may be completely wrong, but I am quite confused and the most is not totally clear to me.
Sorry, for this is coming off topic, but let me share my thoughts. See it as as proposal, its just what i have learned from a naive point of view.
The well known root of all evil its that the strings are processed by Parsedown and
Before try to solve this, there are several cleanup tasks to solve before, to make the path clean and straightforward to follow.
I think merging your PR (https://github.com/mantisbt/mantisbt/pull/1834) would be a good start, because having this function already present makes the feeling of success nicer.
1. cleanup quotings
For decades the opening arrow
2. cleanup tables
Parsedown provide a helpfull method where all "marked" elements accessible. Use it.
3. cleanup table tests
4. cleanup the blockHeader part
todo: Clarify what a valid issue mention is.
Modify the regex to meet the mantis requirements.
5. cleanup formatting process
Parsedown provides a usefull method called
After that and merging all parts together the whole part looks very nice and its a huge impact for user experience.
The branches are all independent but could make it a cascading series. What do you think about? I am not experienced in contributing, so this may look strange to you, but I have no idea what the right approach is.
Fixing this todos would be a really nice finishing point.
@hotzeplotz many thanks for your in-depth analysis.
At first glance the approach seems good, unfortunately I do not have the time to have a detailed look at your proposal right now, and won't be able to, until end of August.
Please bear with me, thanks for your patience and understanding.