Allow to unpublish extensions

[tomcec]

how to unpublish extension from open-vsx.org once published ?

[spoenemann]

Unpublishing is not supported at the moment because that might break others who depend on a published extension. We could consider going for an approach like npm, i.e. allow to unpublish only in certain circumstances:

https://docs.npmjs.com/unpublishing-packages-from-the-registry

[zimlu02]

Hi,

I also feel unpublish/delete/hide option is important. At least for a case, the wrong version got published... Or how we can easily test our extensions are supported on openvsx?

Also how we can update the extension with a newer version?

[zimlu02]

Actually all mentioned reasons for unpublish seem valid:

• Published something accidentally.
• Wanted to test.
• Published content you didn’t intend to be public.
• Want to rename a package.

[spoenemann]

Ok, regarding this as a feature request.

Also how we can update the extension with a newer version?

Just publish it again with a different version.

[spoenemann]

In the meantime, you can create an issue at https://github.com/eclipse/open-vsx.org/issues if you want an extension (or a specific version of it) to be removed.

[venkatzhub]

This would be a good feature to have - just to even test the process of publishing something.

[GitMensch]

#24 brought up another thing related to dependencies - old versions. In this specific case there was a restructuring and split extensions, with some old versions of A depending on a now obsolete B. To have a solution in the future I suggest to allow not only unpublish (which should not be possible as long as there are existing dependencies) but also to be able to make an extension obsolete (which would need a mandatory notice). Obsolete extensions would still be available but could be left out of the search on the registry (possibly only be shown with a special "also search for obsolete items") and/or be always shown "last" in the results.

[HansUXdev]

Can you reversion this or unpublished it? I didn't realize it was set to 999.0.0-alpha when I published it. https://open-vsx.org/extension/hediet/vscode-drawio

[zimlu02]

Can you reversion this or unpublished it? I didn't realize it was set to 999.0.0-alpha when I published it. https://open-vsx.org/extension/hediet/vscode-drawio

Couldn't you publish again with the correct version number?

[GitMensch]

Couldn't you publish again with the correct version number?

This would be possible but even then the version with the highest version number is 999 and would win, I guess at least in some places.

[spoenemann]

Here's a good point against removing published versions: https://github.com/eclipse-theia/theia/pull/8800#issuecomment-737048974

I would propose the following:

• Owners of a namespace are allowed to remove an extension version within 7 days after publishing it.
• Removing an extension after 7 days requires to create an issue.
• Removing an extension from a public namespace requires to create an issue.

[brianking]

@spoenemann I read that comment, and my understanding is that the argument against removing published versions is that they can be potentially overwritten by malware. Is that correct? Why would a client overwrite an already installed version though?

[spoenemann]

I read that comment, and my understanding is that the argument against removing published versions is that they can be potentially overwritten by malware. Is that correct?

Yes. Another argument is that others may depend on an extension for their daily work, so we shouldn't take the removal of extensions too lightly. Other registries such as npmjs.com and maven.apache.org do not allow to remove published packages.

Why would a client overwrite an already installed version though?

That will typically not happen if you're using a single desktop client. But automatically installing the same version again can happen if you're using an online IDE or auto-sync your IDE settings between multiple clients / devices.

[brianking]

In this case the guidelines you propose seem reasonable.

[goyalyashpal]

• i will be against the option of unpublishing,
• fdroid also doesnt support unpublishing.
• in the case a wrong version got published, there are procedures for that as @spoenemann said above https://github.com/eclipse/openvsx/issues/58#issuecomment-607902879 i have never seen such an event on f-droid (ig bcz the procedure for inclusion takes roughly 7 days, and actual involvement of f-droid team as well as the author). but i guess they would archive such an app, not remove it.

if the open-vsx team would like to talk to someone with experience in f-droid, then @izzysoft sorry to call u here without consulting beforehand, would u like to assist a little??

Refer: https://f-droid.org/en/docs/FAQ_-_App_Developers/#how-do-i-get-my-app-removed

[GitMensch]

The main difference between F-Droid and Open VSX is that the former is an installation while the later is the server software that anyone may use to create a registry.

In general and also for the open-vsx.org instance I'd I vote for a way to mark extensions as "obsolete" and/or "unmaintained". If the registry can check that no other extension depends on the extension I'd be fine also with an "unpublishing" option. In any case: all of these would need to be added to the both the server side and the osvx binary. It would also be nice to be able to configure the server side which of these options are accepted in the registry.

Note: open-vsx.org (which is a public instance of Open VSX) still allows publishing of un-free extensions without a source reference, the only point is "needs a license"; and it also has its own FAQ entry about "How do I Unpublish an Extension?".

[goyalyashpal]

former is an installation

hmm? f-droid too has catalog of apps in its index. i dont think i understand what u wanted to say here.

a way to mark extensions as "obsolete" and/or "unmaintained"

yep, i agree with that. like i said above, "archiving" thing above in case of f-droid is much similar to this

open-vsx.org (which is a public instance of Open VSX)

oh, so these are 2 different things @@@@ - wasnt aware of that

[GitMensch]

open-vsx.org (which is a public instance of Open VSX)

oh, so these are 2 different things @@@@ - wasnt aware of that

Yes, it is similar with F-Droid (the possibly only instance) and fdroidserver (there are not clients for publishing in this case because there is a single metadata repository for the server).

Open VSX is also one of the ways to "locally" host vscode compatible extensions, which is sometimes important because of "lab/closed environments" without any internet access; while this theoretically should be able with fdroidserver I don't know of people doing this for Android.

[IzzySoft]

For the part I was addressed by @yashpalgoyal1304 – at F-Droid apps do not get "removed", just "moved", to the archive repo. Cases where an app is entirely removed are absolutely rare – and I cannot remember a single occasion a once listed app was really "deleted".

[IzzySoft]

@GitMensch "F-Droid (the possibly only instance)" – ahem… There are many 3rd-party repositories you could call "instances" (e.g. mine as the largest such, featuring 750+ apps currently). Each repository has its own set of rules. From my repo e.g. apps indeed do get removed – e.g. when they finally reached "F-Droid proper".

[GitMensch]

@GitMensch "F-Droid (the possibly only instance)" – ahem… There are many 3rd-party repositories

Thanks for the info, this part was NEWS to me! Cool - thanks for your contribution to free software, and for letting me know about that.

[IzzySoft]

Gladly! Then let me also add that there are multiple alternative F-Droid client apps as well, some coming with quite a few 3rd-party repositories pre-configured so users just need to toggle them on (or off), making more than 4k apps available at their fingertips. Without the need of accounts, no walled-gardens – enjoy the freedom of FOSS :smiley:

[radeksimko]

We ran into a case where unpublishing/withdrawing or at least some way of mitigating mistakes would've been useful and I believe this can still be done in a safe way.

I didn't notice until it was too late that ovsx available from npm is an old version https://github.com/eclipse/openvsx/issues/450 and accidentally published a platform specific (darwin/arm64) vsix as universal.

I understand the arguments about security, but I still believe that ability to mark particular versions as "deprecated" or "broken" - without necessarily impacting anyone who already installed these versions - would be helpful. I'd be fine with users staying on broken versions if they already installed those, but if I know I made a mistake I'd really like to prevent more users running into it.

My reason for withdrawal may be more benign, but there could also be a security vulnerability in a particular version and the ability to withdraw such a version before publishing a patched one seems even more desirable.

[jdsatava127]

Are the instructions that https://github.com/EclipseFdn/open-vsx.org/ uses to delete an extension published anywhere? Publishing them would support teams running local instances of openvsx.

[spoenemann]

There are guidelines in the Wiki: https://github.com/EclipseFdn/open-vsx.org/wiki/Guidelines-on-Deleting-Extensions

The admin UI is unlocked by setting a user's role to 'admin'. Currently this can be done only through direct manipulation of the database, i.e. use psql and set this column for the admin users.