Redmine

Right of the hook, I think I'd rather prefer if we standardize on exactly one Markdown formatter. That way, we don't have to deal with the intricatities and potential (security) issues resulting from an overly generic integration. I'd also be fine with making this one markdown library a non-optional dependency.

With that being said, if you have a specific use-case in mind for having support for multiple optional markdown libraries, could you describe in more detail how this would be useful?

Holger Just wrote:

Right of the hook, I think I'd rather prefer if we standardize on exactly one Markdown formatter. That way, we don't have to deal with the intricatities and potential (security) issues resulting from an overly generic integration.

I couldn't agree more in the context of what the Redmine core should provide.

Holger Just wrote:

I'd also be fine with making this one markdown library a non-optional dependency.

I don't know if that is the best solution. For deployments that don't need the feature added with #29752 and don't use any Markdown formatters, it would mean that Redmine adds dependencies (thus adding to Redmine's attack surface) that will not be used.

Holger Just wrote:

With that being said, if you have a specific use-case in mind for having support for multiple optional markdown libraries, could you describe in more detail how this would be useful?

Yes. I know of at least two Redmine user groups (± 100 deployments combined, all off-label usage [i.e. not (software) development]) that use a shared kramdown formatter for 10+ years. They all omit installing the Redcarpet gem required for the current core Markdown formatter, based on the assumption that not-installed software cannot act as an attack surface for their Redmine deployment.
Now, with this setup they are missing the functionality for Markdown attachments provided by #29752, while they do have a Markdown formatter available for use.

With all that being said, I just want to make clear that I don't propose to add any of the mentioned (Textile and Markdown) formatter alternatives to the Redmine core. Instead, what I wanted to convey with this issue is that given that the core provides support for custom formatters, the functionality provided by #29752 shouldn't be bound to the core formatters only.

Good to note is that this issue is less problematic for Textile because:

1. The only Ruby libraries for Textile parsing are Redmine-maintained RedCloth3 and upstream RedCloth 4.x.
2. Redmine provides the non-optional, Redmine-maintained RedCloth3 library as part of the core.

As such, within the context of #29752, the only issue with it is that it effectively only provides another Textile flavor; the functionality provided by #29752 still largely works when Redmine is using a custom Textile formatter that is based on RedCloth 4.