Allow reuse and resubmit IDs of deprecated / SDK-v1 addons in addon exchange

With the end of SDKv1 support, the great majority of the Construct 3 addon landscape was beheaded and now users don't know how to update their unsupported projects.

Many addon devs are trying to carry this crisis by porting some of the addons from SDKv1 to SDKv2, even though they aren't the original authors of them. However, there's no current way to upload these ported addons to the exchange.

Allow that either explicitly marked "deprecated" addons IDs can be resubmitted or from all the SDKv1-only addons.

Suggestion ticket which hopefully won't be ignored like this one from a year ago.

I don't think this is a straightforward thing to do. It violates a fundamental security property that only the addon author has permission to update their own addon. Further, we absolutely do not want to allow people to submit new addons with the same ID as existing SDKv2 addons, as that will result in compatibility nightmares. So even if we only allow submitting an SDKv2 addon with the same ID as an existing SDKv1 addon, that author has then "claimed" the SDKv2 addon ID and nobody else can publish a new SDKv2 addon using that ID. So if someone uploads a partial port of an SDKv1 addon to SDKv2, then abandons it, it's still the case nobody else can publish a new and better port of the original SDKv1 addon. It even opens up the possibility someone could claim a popular, un-ported SDKv1 addon, develop a malicious addon as an SDKv2 port, and then have the auto-updater distribute the malicious addon to everyone. Installing an addon from one developer doesn't mean you inherently trust another developer.

Meanwhile I think it's reasonable to say you should have the consent of the original addon developer before publishing an update to their addon, especially if it was not originally published under an open-source license, in which case obtaining their consent is likely a legal requirement. If you can reach them to get their consent, then presumably you can also send them your SDKv2 port and ask them to publish that for you. Another problem is if another author does an SDKv2 port, and then the original author turns up and does an SDKv2 port for the original addon, which should the addon auto-updater choose? Duplicating addon IDs fundamentally creates an ambiguity which then causes follow-on problems like that.

So I think this is in the category of things that sounds obvious but actually has a bunch of complications. It is the original addon developer's responsibility to update their addon, and users only have implied trust in the original addon developer and should not be assumed to trust some other developer updating their existing addon. Outside of that, distributing unofficial ports separately, at your own legal risk, and at the user's risk if they choose to use it, at least avoids the problems caused by allowing other authors to essentially overwrite or duplicate other developer's addons, possibly without their consent.

I don't think this is a straightforward thing to do. It violates a fundamental security property that only the addon author has permission to update their own addon.

Ashley Yeah, I thought of that too. That's why I mentioned maybe only explicitly marked as deprecated addons by the author. I'm of course talking about the cases where the original addon developer has given authorization.

and users only have implied trust in the original addon developer and should not be assumed to trust some other developer updating their existing addon

I'm not talking about making an auto-update. The addon should still be treated as a different addon. But the same ID allows users to replace the unsupported addon.

Currently the only way to do it is by modifying the .c3proj. Something I've done many times and don't have problems in modifying any of the JSONs generated by Construct directly. However, suggesting that to normal users is a whole different thing, and it's what my suggestion aims to solution.

If you think deprecated addons should still be protected, could you at least look the suggestion of github.com/Scirra/Construct.net-website-bugs/issues/205 that has been ignored for over a year?

Maybe being able to replace deprecated addons and SDK-v1 addons is too much of a security risk. But don't just turn away from the problem. At least let's discuss another alternatives, such as the one suggested over a year ago.

I think it's reasonable to say you should have the consent of the original addon developer before publishing an update to their addon, especially if it was not originally published under an open-source license, in which case obtaining their consent is likely a legal requirement.

Also if you really want to talk about legal stuff and are really concerned about that, you should probably update the addon exchange upload form. As presumably you can only upload MIT licensed works, in which case, there's not even a speck of the legal requirement you're talking about.

> It violates a fundamental security property that only the addon author has permission to update their own addon.

That's why I mentioned maybe only explicitly marked as deprecated addons by the author.

Marking your addon deprecated does not mean "I give other developers permission to overwrite my addon" and I think it would be wrong of us to use that setting in that way.

I'm not talking about making an auto-update. The addon should still be treated as a different addon.

The entire addon system is set up so the addon ID is what defines an addon, so a different addon with the same ID is not in fact a different addon and there isn't currently a system set up to be able to identify such addons as different. Besides, if the auto-updater doesn't update such addons, then users still need to manually hunt down an updated addon.

If you think deprecated addons should still be protected, could you at least look the suggestion of github.com/Scirra/Construct.net-website-bugs/issues/205 that has been ignored for over a year?

If the original addon developer is active enough to add someone as a maintainer, then why not just send them the ported code to publish? The real problem is addon developers who have become inactive and unreachable, in which case implementing an addon maintainers feature does not help the situation at all.

I'm afraid I don't see any easy answers here.

I’m the one who has been porting dozens of these addons recently, and I have to weigh in here because this isn't just about "fixing broken projects"—it's about a massive security liability that hasn't been fully addressed in this thread.

Ashley is 100% right about the security risk, but I want to take it a step further. We’re not just talking about a plugin "not working." We’re talking about Supply Chain Attacks. A malicious actor could easily "port" a popular SDK v1 addon, use the same ID, and hide a script inside a bundled dependency (e.g., import { core } from './bundle.js';). If a user unknowingly updates to this "ported" version and publishes their game, they risk:

App Suspension: Google Play/App Store detecting malicious SDK behaviors.

Account Termination: The "death penalty" for mobile developers—losing their Play Console account permanently.

Financial Loss: For many, this is their livelihood.

As someone doing the heavy lifting of porting these addons, I absolutely refuse to be held responsible for what happens if we allow a "free-for-all" on ID reuse. If I port a plugin and someone else "shadow-updates" it with a malicious ID-match.