Using plugins should require risk consent

Dear sourceresses and sourcers,


My first take on this: You really must be loving these community plugins, dont you? :innocent: (because this will surely be a hit to the ecosystem of community developed plugins - less ppl installing, less feedback, less motivation, less etc.)

My second thought: Well, i can easily envision a benevolent thought process behind all this when pulling the alledged concerns/needs of your paying customerbase into the bigger picture.

So … i would like to abstain from asking anything but:

  • Were your users (non- and/or paying) integrated into the decisionprocess to invest into developing this MMF?
  • And if yes … may i ask: in which way?


Hi Daniel,

This MMF was driven by security concerns. You may be aware that in 2020 a number of SonarQube instances were found to be exposed on the internet with the default admin credentials still in place (reference). While that was purely user error, it caused us to step back and take a fresh look at the security of SonarQube instances.

One thing we realized is that while we can ensure the integrity of what we (SonarSource) provide, we can’t do that for community plugins. And, given the fact that (a “long” time ago) we used to provide our functionality through the Marketplace (nee Update Center) it’s possible that some users may not be aware of the distinction.

So our goal here was to provide a tiny wake up call to make sure that people are aware that they’re using non-SonarSource functionality, and they do so at their own risk. I understand your concern about a negative impact on plugin maintainers and users. But if we had delivered this tiny wake up call as a mere disclaimer in the interface… Well, surely you know how often such things are actually read.

At the same time I want to assure you that we are concerned with fairness in our handling of the plugin “community” (maintainers and users). Please know that the goal is not to inhibit this community. Merely to make sure the cards are on the table.


Hi SonarSource,

What are the reasons behind this being implemented in the commercial editions only ? and why don’t you want to make it configurable for the commercial editions, so that the customers themselves can decide if they want to “stick” to the old way of installing plugins or the new manual (and very very time consuming) way via for example a startup property ?

You implement a “force” mechanism without asking the customers of the commercials editions if this should be configurable and I don’t get why this manual installation should “only” be for commercial editions. It’s a “one-size-fits-all” (one size fits nothing as I tend to say) approach - where you decide what’s best for customers. That’s a no-go :frowning:

In our company I am the person in charge of the update of SonarQube – another person is in charge of the plugin updates and all the UI settings (rulesets, portfolios etc). The other person do not have access to the filesystem, so on every update of a plugin or when adding new plugins the other person needs to have me to work. (Dev and Ops seperation right :smile: ) - that’s a really annoying extra process. Think about if Atlassian did this on their Jira, Confluence and Bitbucket products without asking the customers… It’s the first product ever where I see this approach on the plugin eco-system. Give the power to the people and remove the force mechanism in the commercial editions via the possible to configure this as a system startup property. Thanks.

When I need to update to the new manual way of installing plugins I need to find all the “download urls” for the plugins and put them into our Ansible configs. It’s really a “headache” for us in our company.

So once more (also asked to our account manager): Why don’t you want to make it configurable for the commercial editions (like the community editions), so that the customers themselves can decide if they want to “stick” to the old way of installing plugins or the new manual (and very very time consuming) way. I haven’t found that answer in the supplied information.

Kind regards
Claus Nielsen

Hi G Ann Campbell - do you have any input to my message in this thread ?

Hi Claus,

TBH it wasn’t clear to me that you were actually looking for answers, especially since - as you say - you asked your account manager, who I’m confident has gotten back to you. I provided the main motivation above. Nonetheless, I’ll expand a bit with a snippet lifted from an internal discussion:

In our commercial editions we are providing an enterprise-ready solution, one that is scalable and works well. We can not support what is or isn’t happening with some of the plug-ins in the community and we want there to be a clean line between what we are providing you and what is not part of SonarQube.

Regarding this:

I understand that the extra steps are annoying. I think most people find changing procedures for security compliance irritating at first :smiley:. But if this is happening very often, I would wonder at your use case. Since I’m the one who manually processes Marketplace updates, I’m well aware that new plugin versions don’t come out every day.

You make a fair point about the discoverability of plugin download URLs - one we’ll hopefully address soon. In case it helps, here’s where the metadata for Marketplace plugins is kept.


Thanks a lot for your reply :slight_smile:

Maybe an idea was to enrich the documentation with a link to GitHub - SonarSource/sonar-update-center-properties to ensure that the users of the commercial version is quickly able to find the plugin urls - not some fake “man in the middle” urls but approved by SonarSource as plugin urls. Just input.

I respect that you would not like to support community plugins in the commercial version - but I still think the decision should be one the customers should take. For example by enabling a system property and thereby being able to download the plugins without fiddling with the filesystem. By enabling this system property the customer themselves take the security risk. For customers with a commercial license but without support license (as us) this would be a 100% match.

Some reflections:
Imagine if Atlassian or other vendors took the same decision as SonarSource… Jira, Bitbucket and Confluence without community plugins…

It’s a strategy for a product and I respect your strategy but IMHO I think you should really treat the commercial customers with great care and not take decisions on behalf of them. Take my advise as input for a more customer centric strategy :wink:

I just read and answered Marketplace disabled in non-Community versions? - #5 by daniel which triggered me to continue here…

Sadly you found no words to address the following question:

Also: If your last sentence is truly ment that way … than (in my opinion) some warnings plus “requiring and documenting consent” would have put all “cards on the table” as you stated.

Actively destroying convenience has - to me - a rather strong smell of inhibition, tbh.

But of course, your product, your choice.

If i may, i’d like to suggest some kind of questionnaire sent to your customers to find out how well recepted(?) this new feature is and what might be done in consequence to mitigate any negative perceptions.

You call this a tiny wakeup call?

This is really a downer for administration. Since for us, the maintenance of tools like SonarQube is made not by an entire IT department, but by some developers here, that are doing this work on top of their normal work.

At least you should have left the option to reenable this feature and leave the decision on that to the user, after initially disabling it.

Maybe good for bigger departments (I doubt) but not for us here and as I heard in other posts, for many other people also not.

maybe you rethink this and give us the ability to reenable this again.