Found a security vulnerability in a paid for add-on but it still isn't fixed...
Permalink 1 user found helpful
Hi All,
I do not want to cause drama but I do have a major concern. I reported a security vulnerability to a core contributor back in January concerning an Add-On that I purchased. I even went as far as to submit a patch to fix the vulnerability.
Fast forward to today, while troubleshooting a different C5 bug I realized that I had never received an email or any sort of notification that this vuln was fixed. I downloaded the newest version of the Add-On and went back through the code. Guess what, the vuln is still in place.
I am not looking to blame anyone as I think the communication channel I used was the wrong one. But given this information I'd like to ask the following questions of the community.
- Who do we report Add-On vulns to?
- How will the users of an insecure Add-On be notified?
- Whose responsibility is it to notify said users?
Thanks,
Jared
I do not want to cause drama but I do have a major concern. I reported a security vulnerability to a core contributor back in January concerning an Add-On that I purchased. I even went as far as to submit a patch to fix the vulnerability.
Fast forward to today, while troubleshooting a different C5 bug I realized that I had never received an email or any sort of notification that this vuln was fixed. I downloaded the newest version of the Add-On and went back through the code. Guess what, the vuln is still in place.
I am not looking to blame anyone as I think the communication channel I used was the wrong one. But given this information I'd like to ask the following questions of the community.
- Who do we report Add-On vulns to?
- How will the users of an insecure Add-On be notified?
- Whose responsibility is it to notify said users?
Thanks,
Jared
Thanks John, your perspective as a marketplace dev is helpful and appreciated. I am also interested in what buyers and users expect. And if their expectations are reasonable.
> (a) The developer - as you have - and give them a chance to fix it.
To be clear, I reported this to a core contributor and someone on the marketplace team. I did not report this to the dev of the plugin. My reasons for this were basically my past experiences. Generally a marketplace has more skin in the game and has more motive to be transparent. I've reported stuff to the plugin dev before only to see them
a) not update their code
b) update but tell no one
c) update and alert their buyers of the critical nature of said update
> The severity of this bug
We reviewed the bug. I could own your site if the plugin was installed and its basic functionality was enabled (the whole reason you'd buy it). From there embedding some javascript to start along the path of exploiting your user's machines or popping the server is a small script. (But such is the power of the C5 Admin user)
I hope it is obvious that I am not trying to make a huge deal out of this. I only bring it up because of the communication break down. I know others in the security field who would use miscommunications like this as justification to showcase an exploit and not care about the fallout to the products, teams, and community.
Anyway, I see this as an opportunity to amend the following with a clear path for issues like this.
https://www.concrete5.org/developers/security...
Thanks again,
Jared
> (a) The developer - as you have - and give them a chance to fix it.
To be clear, I reported this to a core contributor and someone on the marketplace team. I did not report this to the dev of the plugin. My reasons for this were basically my past experiences. Generally a marketplace has more skin in the game and has more motive to be transparent. I've reported stuff to the plugin dev before only to see them
a) not update their code
b) update but tell no one
c) update and alert their buyers of the critical nature of said update
> The severity of this bug
We reviewed the bug. I could own your site if the plugin was installed and its basic functionality was enabled (the whole reason you'd buy it). From there embedding some javascript to start along the path of exploiting your user's machines or popping the server is a small script. (But such is the power of the C5 Admin user)
I hope it is obvious that I am not trying to make a huge deal out of this. I only bring it up because of the communication break down. I know others in the security field who would use miscommunications like this as justification to showcase an exploit and not care about the fallout to the products, teams, and community.
Anyway, I see this as an opportunity to amend the following with a clear path for issues like this.
https://www.concrete5.org/developers/security...
Thanks again,
Jared
> I did not report this to the dev of the plugin.
First point of communication should always be the developer.
Core developers contributing to the core on Github have no responsibility for marketplace addons.
There isn't any marketplace team. There are developers with addons in the marketplace. There are 'community leaders' who are just those who have contributed in some way or another for a while. There are members and admins of the PRB. There is the Portland Labs marketing team, but no marketplace team. PRB admins may get involved in sorting out addon quality and support issues, but in a case like this it would be passed on to Franz.
So making a first report to anyone other than the developer or Franz is just adding another link into a game of Chinese whispers and decreasing the likelihood of the issue being addressed.
First point of communication should always be the developer.
Core developers contributing to the core on Github have no responsibility for marketplace addons.
There isn't any marketplace team. There are developers with addons in the marketplace. There are 'community leaders' who are just those who have contributed in some way or another for a while. There are members and admins of the PRB. There is the Portland Labs marketing team, but no marketplace team. PRB admins may get involved in sorting out addon quality and support issues, but in a case like this it would be passed on to Franz.
So making a first report to anyone other than the developer or Franz is just adding another link into a game of Chinese whispers and decreasing the likelihood of the issue being addressed.
What about adding onto the existing support structure we already have in place?
Using Block Designer only as an example:
https://www.concrete5.org/marketplace/addons/block-designer/support/...
We currently have Pre-Sale, Discussion, and Ticket. We could add Security Vulnerability as a new type of support request.
1) This would provide the Marketplace developers a single place to go to address all the concerns.
2) By making Security Vulnerability tickets private by default, would allow the reporter to post the security exploits without them becoming publically available.
3) This would also allow Concrete5 to report and track known exploits, and perhaps take some action. For example: If an exploit hasn't been addressed after X days, either fixed, or an explanation as to why it's not a vulnerability, the add-on can be pulled
Using Block Designer only as an example:
https://www.concrete5.org/marketplace/addons/block-designer/support/...
We currently have Pre-Sale, Discussion, and Ticket. We could add Security Vulnerability as a new type of support request.
1) This would provide the Marketplace developers a single place to go to address all the concerns.
2) By making Security Vulnerability tickets private by default, would allow the reporter to post the security exploits without them becoming publically available.
3) This would also allow Concrete5 to report and track known exploits, and perhaps take some action. For example: If an exploit hasn't been addressed after X days, either fixed, or an explanation as to why it's not a vulnerability, the add-on can be pulled
Is it Pro Blog?
Is it Pro Blog?
Alright so it turns out that my report was forwarded to the developer and the developer did nothing with it.
This is an abuse of trust and is unacceptable.
If we want C5 and its marketplace to be respected and not known as a place where hackers can come hangout and expect to exploit plugins we need a way to facilitate trust through actions.
My suggestions are the following.
- Create functionality to privately report vuln to Add-On Dev (like Tim suggests)
- Convert report from private to public after a certain date
- Aggregate all public reports into an RSS feed so that community can monitor them?
- Since we can't offer money for reports, put people's names on a wall or something?
This would allow the Marketplace to facilitate the reporting. It would get the info to the Dev in a way that is accountable. But it would put the onus on the community to eventually vet if a report was legit or not when the report goes public. If the Dev asserts that the problem is no big deal, but the community says otherwise, we can either advocate the Add-On's removal or the social pressure will give the Dev the chance to change course and address the concerns.
I'm ok if people need more time to fix stuff but a special request like that should only be allowed 1x every (n) months. If it is happening more than that, you need to level up your programming skills.
Just my thoughts.
Thanks,
Jared
This is an abuse of trust and is unacceptable.
If we want C5 and its marketplace to be respected and not known as a place where hackers can come hangout and expect to exploit plugins we need a way to facilitate trust through actions.
My suggestions are the following.
- Create functionality to privately report vuln to Add-On Dev (like Tim suggests)
- Convert report from private to public after a certain date
- Aggregate all public reports into an RSS feed so that community can monitor them?
- Since we can't offer money for reports, put people's names on a wall or something?
This would allow the Marketplace to facilitate the reporting. It would get the info to the Dev in a way that is accountable. But it would put the onus on the community to eventually vet if a report was legit or not when the report goes public. If the Dev asserts that the problem is no big deal, but the community says otherwise, we can either advocate the Add-On's removal or the social pressure will give the Dev the chance to change course and address the concerns.
I'm ok if people need more time to fix stuff but a special request like that should only be allowed 1x every (n) months. If it is happening more than that, you need to level up your programming skills.
Just my thoughts.
Thanks,
Jared
The PRB reviews add-ons and themes as they're submitted, but due to time constraints and the desire to let marketplace devs who have proven themselves actually manage their work in a timely fashion, having them review every additional update isn't going to happen.
We do have a vulnerability disclosure program just as you describe for the core cms itself at hackerone.com/concrete5
We have an email we also offer people can let us know about security issues on.
I think the best practice here in the future would be:
1) Send a private message to the developer detailing the issue and asking for a response.
2) Forward a copy of that to our security email; security@concrete5.org
3) If it's really bad enough, we'd absolutely pull the listing and jump through some hoops to send an email to people who might have the listing installed.
Just to be clear, we break security concerns into these rather important and clear distinctions:
Levels of Severity
Open Door - A clear method where someone can immediately gain any type of unintended administrative access through a bug in the system. This would put a website at risk from an external attacker or a disgruntled editor with limited permissions. It is a clear documented attack that always grants access to someone who should not have it. This type of exploit would be considered a top priority and would likely force an immediate point release of the core to resolve.
External Attack Vector - A bug that an external attacker might use in conjunction with other techniques to gain access or get data. No administrative access is required to exploit the bug. The bug does not provide access on its own. It would have to be part of a larger attack, often involving some social engineering. These are considered a high priority and are typically patched immediately by the core team in github and launched in the next version of the core.
Internal Attack Vector - A bug that requires someone already have some type of administrative access to the CMS. This might just change the experience of the CMS, or be part of a more complicated attack that might hypothetically gain more access than they should have. These are considered important to clean up over time.
We do have a vulnerability disclosure program just as you describe for the core cms itself at hackerone.com/concrete5
We have an email we also offer people can let us know about security issues on.
I think the best practice here in the future would be:
1) Send a private message to the developer detailing the issue and asking for a response.
2) Forward a copy of that to our security email; security@concrete5.org
3) If it's really bad enough, we'd absolutely pull the listing and jump through some hoops to send an email to people who might have the listing installed.
Just to be clear, we break security concerns into these rather important and clear distinctions:
Levels of Severity
Open Door - A clear method where someone can immediately gain any type of unintended administrative access through a bug in the system. This would put a website at risk from an external attacker or a disgruntled editor with limited permissions. It is a clear documented attack that always grants access to someone who should not have it. This type of exploit would be considered a top priority and would likely force an immediate point release of the core to resolve.
External Attack Vector - A bug that an external attacker might use in conjunction with other techniques to gain access or get data. No administrative access is required to exploit the bug. The bug does not provide access on its own. It would have to be part of a larger attack, often involving some social engineering. These are considered a high priority and are typically patched immediately by the core team in github and launched in the next version of the core.
Internal Attack Vector - A bug that requires someone already have some type of administrative access to the CMS. This might just change the experience of the CMS, or be part of a more complicated attack that might hypothetically gain more access than they should have. These are considered important to clean up over time.
So would license holders get notified if an addon or theme is pulled due to security concerns?
I appreciate your effort to be helpful. That part, I value.
I do not value your piety and process. A support ticket is ALWAYS the best way to communicate with a developer.
I get hundreds of emails a week for any range of things related to C5. I don't always see all of them. And sometimes, even if I respond...if there is not a support ticket, I possibly forget or lose sight of that issue.
In the future, please put a ticket in. Even if you think it's to no avail.
Again, I really do appreciate your expressed concern and time and effort to try and raise the bar of quality and security in code. I just wished you would have put a ticket it. They are there to help dev's prioritize.
As this is getting addressed, and because we actually do not have any way to notify all users as dev's, would you be willing to take down your blog post?
I do not value your piety and process. A support ticket is ALWAYS the best way to communicate with a developer.
I get hundreds of emails a week for any range of things related to C5. I don't always see all of them. And sometimes, even if I respond...if there is not a support ticket, I possibly forget or lose sight of that issue.
In the future, please put a ticket in. Even if you think it's to no avail.
Again, I really do appreciate your expressed concern and time and effort to try and raise the bar of quality and security in code. I just wished you would have put a ticket it. They are there to help dev's prioritize.
As this is getting addressed, and because we actually do not have any way to notify all users as dev's, would you be willing to take down your blog post?
As the maintainer of several projects myself, I know how annoying it is to get emails in your personal inbox rather than through an issues tracker.
Except for vulnerability reports.
Those, I *ask* people to email me about. This is best practice, as it is irresponsible for someone to disclose the details of an exploit publicly before a patch is made available to end users. Many projects even provide a PGP public key for truly private disclosures. For an example of a well-executed security policy, check out Go's:http://golang.org/security
Except for vulnerability reports.
Those, I *ask* people to email me about. This is best practice, as it is irresponsible for someone to disclose the details of an exploit publicly before a patch is made available to end users. Many projects even provide a PGP public key for truly private disclosures. For an example of a well-executed security policy, check out Go's:http://golang.org/security
Well I would rather see a ticket and solve it immediately than miss an email or forget about it and then have a public blog post about it screwing thousands of users.
I also think a "update is required" option for critical issues should be implemented on the core site personally.
I also think a "update is required" option for critical issues should be implemented on the core site personally.
If the vuln is as serious as described, and the vendor isn't fixing it, then it should be removed from the marketplace until its fixed. Or atleast get a big warning "WARNING: THIS PLUGIN ISN'T SECURE! INSTALL AT YOUR OWN RISK"
The last thing we need is insecure plugins for concrete, just look at Wordpress, most exploits happen via plugins.
The last thing we need is insecure plugins for concrete, just look at Wordpress, most exploits happen via plugins.
Not a fan of posting the big warning, as the public can see something marked insecure, buy a copy and then figure out how to exploit.
It would be like putting a sign in the front yard of a house for rent saying "INSECURE LOCKS ON THESE DOORS, DON'T RENT". It just gets the attention of the bad folks to look into it further.
It would seem more appropriate to notify anyone with a license to update or uninstall if necessary, depending on the severity of the issue.
Just my thoughts.
It would be like putting a sign in the front yard of a house for rent saying "INSECURE LOCKS ON THESE DOORS, DON'T RENT". It just gets the attention of the bad folks to look into it further.
It would seem more appropriate to notify anyone with a license to update or uninstall if necessary, depending on the severity of the issue.
Just my thoughts.
Boom!
Seriously. I just blew up my database using a freaking HTTP GET request. This plugin needs to be removed and everyone who purchased it needs to be notified.
http://imgur.com/ew13PP5
Seriously. I just blew up my database using a freaking HTTP GET request. This plugin needs to be removed and everyone who purchased it needs to be notified.
http://imgur.com/ew13PP5
So which plugin is it? I want to make sure I didnt install it on a customers site. If it is ProBlog I couldn't get that plugin to work in the first place so I ended up followinghttp://documentation.concrete5.org/tutorials/setup-a-simple-blog-wi...
A bit cryptic, but I take it the screenshot is the outcome of your changing the root password via this vulnerability?
Pretty sure that would be from injecting a "drop table Users;' command.
Thanks, seems obvious now you have pointed it out :-)
Something is not clear to me here,
the vulnerability concerns the PE package according to the post. But the email sent to the dev indicates the PB package.
So which is it?
the vulnerability concerns the PE package according to the post. But the email sent to the dev indicates the PB package.
So which is it?
Reading through the linked blog post, its PE.
Yes but in the linked Post, there is a copy of the email sent to the developer and it references PB not PE
The exploit I posted is for ProEvents but both had vulnerabilities.
The image posted had the wrong subject in it. The github gists had the correct patch to ProEvents. If there would have been a conversation after the email, I'd have happily apologized for the mistake in the subject.
With that said, it appears to have had a nice side effect as it has forced the developer to fix a vuln in ProBlogs too. As I grep through ProBlogs old code it is potentially just as severe.
http://imgur.com/PCDsDdK
http://imgur.com/rBAofGN
Everyone should update ProBlogs. I haven't reviewed the patch for it yet so I have no idea of the value.
What this thread has accomplished is forcing a developer of a paid plugin to review and patch their vulnerable code bases. Transparency is good. Immediate action is the correct action.
The image posted had the wrong subject in it. The github gists had the correct patch to ProEvents. If there would have been a conversation after the email, I'd have happily apologized for the mistake in the subject.
With that said, it appears to have had a nice side effect as it has forced the developer to fix a vuln in ProBlogs too. As I grep through ProBlogs old code it is potentially just as severe.
http://imgur.com/PCDsDdK
http://imgur.com/rBAofGN
Everyone should update ProBlogs. I haven't reviewed the patch for it yet so I have no idea of the value.
What this thread has accomplished is forcing a developer of a paid plugin to review and patch their vulnerable code bases. Transparency is good. Immediate action is the correct action.
I like how there is a big discussion about me and my products but no support ticket regarding said issue anywhere.
A Couple things :
1) thanks to Fanz, I have a real life now. I have a job. A wife. Two kids. A house. As well as doing my best to maintain these products. Times two, since our genius leader decided to set up two marketplaces.
2) some of you are absolutely inconsiderate jerks. Straight up. Bashing me on IRC, on forums.....classy. Super classy.
3) I had dozens of emails every single day to get a 5.7 version of these products available. I was the First person, with zero documentation for 5.7, to have any sort of product to support C5.7 growth. Some of you shleps boldly claimed "I'm not touched 5.7 until it's further along". I wanted to see it grow. So I stepped up. Spent weeks getting a handful of products. And handled release after release of inconsistent undocumented core changes....basically...fielding support tickets for busted product that was caused by busted core. That was fun.
4) there was one. Singular un-obfuscated injection point. If there are more, please put a ticket in. I welcome it. I don't think having one issue constitutes a crappy product. Franz pointed out a day ago, it's already patched. Should it have been patched earlier when Tim pointed it out......yes. It should have. I cannot say why other than something critical came up in real life or work that allowed that to escape me. Some of this code is over 5 years old. It has evolved. But I dare any of you to turn back the clock and believe for one second you would code the way you do now. The 5.7 versions are quite improved and just like all of you, I have learned a lot over the years and there is some very good quality of code in the newer versions of the app. There is, in fact, also some old code. The re-write was hard enough as it was. (but then again, some of you never lifted a finger to convert code....so how would you even know that.)
5) I am a human being!!!!! As in...a real person. Some of you here are freely bashing me on IRC, harassing publicly in forums....with only one of you sending me an email to let me know. Talk about frustrating.
I'm doing my best. I am sorry that is just not good enough for you guys. Bash away if it makes you feel better.
ChadStrat
A Couple things :
1) thanks to Fanz, I have a real life now. I have a job. A wife. Two kids. A house. As well as doing my best to maintain these products. Times two, since our genius leader decided to set up two marketplaces.
2) some of you are absolutely inconsiderate jerks. Straight up. Bashing me on IRC, on forums.....classy. Super classy.
3) I had dozens of emails every single day to get a 5.7 version of these products available. I was the First person, with zero documentation for 5.7, to have any sort of product to support C5.7 growth. Some of you shleps boldly claimed "I'm not touched 5.7 until it's further along". I wanted to see it grow. So I stepped up. Spent weeks getting a handful of products. And handled release after release of inconsistent undocumented core changes....basically...fielding support tickets for busted product that was caused by busted core. That was fun.
4) there was one. Singular un-obfuscated injection point. If there are more, please put a ticket in. I welcome it. I don't think having one issue constitutes a crappy product. Franz pointed out a day ago, it's already patched. Should it have been patched earlier when Tim pointed it out......yes. It should have. I cannot say why other than something critical came up in real life or work that allowed that to escape me. Some of this code is over 5 years old. It has evolved. But I dare any of you to turn back the clock and believe for one second you would code the way you do now. The 5.7 versions are quite improved and just like all of you, I have learned a lot over the years and there is some very good quality of code in the newer versions of the app. There is, in fact, also some old code. The re-write was hard enough as it was. (but then again, some of you never lifted a finger to convert code....so how would you even know that.)
5) I am a human being!!!!! As in...a real person. Some of you here are freely bashing me on IRC, harassing publicly in forums....with only one of you sending me an email to let me know. Talk about frustrating.
I'm doing my best. I am sorry that is just not good enough for you guys. Bash away if it makes you feel better.
ChadStrat
A lot of people are working very hard on this right now.
This whole thing has been disappointing, across the board.
We will post to the blog on what's happened, happening, and still must happen later today.
This whole thing has been disappointing, across the board.
We will post to the blog on what's happened, happening, and still must happen later today.
@RadiantWeb
Hang in there brother, I'm having a similar situation where I work. All I can say is hang in there, it'll get better :)
Hang in there brother, I'm having a similar situation where I work. All I can say is hang in there, it'll get better :)
Hey Chad,
I'm not a C5 user -- just a concerned reader. But as a software developer I do know how it goes when the work/life balance is overwhelming to maintain. So thank you for the work you put into C5. And congrats on the job!
I'm not familiar with C5's ticketing system but I imagine they're public? Jared emailed you instead of opening a support ticket because it's best for these types of reports to be filed privately. As for the urgency, Jared said he is speaking at a conference tomorrow to recommend C5 in front of hundreds of people, so it makes sense that he wants the product to live up to its commendation.
Most of the criticism here seems to be directed toward C5's marketplace and its design/policies. Most of the "bashing" is just a passionate discussion about how to improve C5's marketplace and vulnerability reporting process, as well as raising some important questions about who is responsible for what. Try not to take it too personally--there are things that everyone involved here can learn from.
Have you considered charging more for these add-ons, or making it a subscription? $30 is awfully low for a one-time payment. ProBlog and ProEvents deliver way more value than that, even with their flaws. You're overwhelmed with working on C5 and maintaining these add-ons, but you're still charging people to use them. Apparently there is a gap between what people are expecting from a product they paid for, and what you are able to deliver. You might be able to close this gap if you charge for the add-ons what they're worth. Maybe you'd be able to spend more time on them or hire someone to help you.
I'm confident you and the C5 staff will be able to come up with a good solution to the issues raised here. Now that the patches have been released, it's just up to the site owners to update. IMO you've done what is required of you.
I'm not a C5 user -- just a concerned reader. But as a software developer I do know how it goes when the work/life balance is overwhelming to maintain. So thank you for the work you put into C5. And congrats on the job!
I'm not familiar with C5's ticketing system but I imagine they're public? Jared emailed you instead of opening a support ticket because it's best for these types of reports to be filed privately. As for the urgency, Jared said he is speaking at a conference tomorrow to recommend C5 in front of hundreds of people, so it makes sense that he wants the product to live up to its commendation.
Most of the criticism here seems to be directed toward C5's marketplace and its design/policies. Most of the "bashing" is just a passionate discussion about how to improve C5's marketplace and vulnerability reporting process, as well as raising some important questions about who is responsible for what. Try not to take it too personally--there are things that everyone involved here can learn from.
Have you considered charging more for these add-ons, or making it a subscription? $30 is awfully low for a one-time payment. ProBlog and ProEvents deliver way more value than that, even with their flaws. You're overwhelmed with working on C5 and maintaining these add-ons, but you're still charging people to use them. Apparently there is a gap between what people are expecting from a product they paid for, and what you are able to deliver. You might be able to close this gap if you charge for the add-ons what they're worth. Maybe you'd be able to spend more time on them or hire someone to help you.
I'm confident you and the C5 staff will be able to come up with a good solution to the issues raised here. Now that the patches have been released, it's just up to the site owners to update. IMO you've done what is required of you.
Very delicately put, mholt.
As a customer of RadiantWeb I am afraid that my experience with posting support tickets has been that there is a delay of a few months in getting a response. I would not advocate that as a quicker way to get a response than email, tweeting his account or going via the RadiantWeb website.
Chad may be good at coding but thus far the evidence is that emotional work is something he needs to focus on. Overly defensive special pleading about having a life outside of Concrete5 development does not come across as a gracious response to legitimate concerns over security issues.
There is a follow up to this thread from Concrete5 security:
https://www.concrete5.org/about/blog/news/security-issue-proevents-w...
As a customer of RadiantWeb I am afraid that my experience with posting support tickets has been that there is a delay of a few months in getting a response. I would not advocate that as a quicker way to get a response than email, tweeting his account or going via the RadiantWeb website.
Chad may be good at coding but thus far the evidence is that emotional work is something he needs to focus on. Overly defensive special pleading about having a life outside of Concrete5 development does not come across as a gracious response to legitimate concerns over security issues.
There is a follow up to this thread from Concrete5 security:
https://www.concrete5.org/about/blog/news/security-issue-proevents-w...
An issue can sometimes exist in an abstract sense, but not be an actual problem when examined in the context of the real world. For example, how important is it if the site administrator can subvert a dashboard page? Certainly not as important as if an un-registered visitor could do the same to inject malicious code through the home page.
Bearing the above in mind:
- Who do we report Add-On vulns to?
(a) The developer - as you have - and give them a chance to fix it. (As a developer, I would give such concerns with my own products my top priority). Need to consider:
(1) After further analysis, was it really a vulnerability?
(2) Was your fix the most appropriate - could it have been fixed elsewhere?
(3) Is it an addon or a core issue?
(b) Having allowed time for (a), notify Franz - as any further action w.r.t keeping the addon in the marketplace or wider action will be his decision.
- How will the users of an insecure Add-On be notified?
- Whose responsibility is it to notify said users?
(c) Ideally the developer should take care of that by releasing an update with information in the version info.
(d) Again, to Franz, for the same reasons as above.