feat: Add GDPR endpoint to openvsx admin API by autumnfound · Pull Request #1982 · eclipse-openvsx/openvsx

autumnfound · 2026-07-21T18:06:18Z

Adds a GDPR endpoint to the OpenVSX API that allows for admin level tokens to request for users to be forgotten. Rather than deleting users, this request will scrub all PII from the existing user records to erase any potential leak of private information. This is done to best retain things like reviews and other user actions within the system while abiding by GDPR requirements.

These deletion requests do not remove or modify any of the internal logging that already exists as there is a business need to retain that type of data, which will have it's own retention policy that will eventually purge those records.

Assisted-by: Claude Sonnet 4.6

autumnfound · 2026-07-21T18:06:44Z

Related to the request: EclipseFdn/open-vsx.org#8200

netomi · 2026-07-30T12:07:24Z

+        // Send a DELETE request to the Eclipse publisher agreement API. Guarded so that
+        // instances without Eclipse integration are unaffected.
+        if (eclipse.isActive() && user.getEclipsePersonId() != null) {
+            eclipse.revokePublisherAgreement(user, admin);


that call requires that there is an active token for the given users to successfully make the call to the internal Eclipse API service.

In the UI, if no such token is present right now (it might be expired), then there is a button to login to eclipse to refresh the token.

Doing that in an API call will require a mechanism to provide the token in a different way.

my understanding is that this endpoint will be used from an internal Eclipse service to remove data for a specific user from Open VSX. It does not make sense to ask Open VSX to connect back to Eclipse API to further cleanup. The originator of this request should do all internal cleanup:

call Open VSX:forget

revoke publisher agreement if needed as the user will be deleted afterwards I guess

The thing w/ the PA that I'm more concerned about is when we pull the EF stuff out, it would leave it in a state that we'd have to remember to go update this. With the thought of decoupling our services in mind, I think this is the right call even if in our case it is a little cludgy.

netomi · 2026-07-30T12:15:48Z

+    }
+
+    @PostMapping(
+            path = "/publisher/{provider}/{authId}/delete",


what is the purpose of that endpoint? It mimicks the above but this one requires a session so would be used from the frontend, but there is no relevant change to the UI in this PR

passing here an authid is also misleading as you call the forgetUser method which expects a login_name which is used as query parameter.

You're right that this one in current state is irrelevant. Do we want to add the ability to forget a user in the admin dashboard? If this is a standalone service ever I can see it being a little more convenient than doing internal token calls.

RE the bad path param, I can update that if we keep it, but I want to check that we want it first

The question is how would this be different from the existing Revoke publisher contributions. If we have an answer to that we can design the different endpoints and make them visible in the UI.

The big difference is that the account gets "tombstoned" in that all user details are scrubbed. The endpoint you mentioned just does user properties without actually modifying the base user, past their PA.

netomi · 2026-07-30T12:21:04Z

+                for (var extension : repositories.findActiveExtensions(namespace).toList()) {
+                    var deactivated = false;
+                    for (var version : repositories.findVersions(extension)) {
+                        if (version.isActive()) {


instead of deactivating the extension, we should now delete them which will keep the metadata of the extension alive but remove the actual extension files

also the user that you want to forget about is the central part not the namespaces he is in.

What matters is what extension versions the user has published, and you have to delete these extension versions as you will revoke his publisher agreement. The invariant of Open VSX is that only extensions with active publisher agreements shall be visible.

netomi · 2026-07-30T12:28:03Z

The PR needs to be rebased on the lasted main branch with the changes to version immutability.

Also the decision to remove or keep extension versions on an criteria of namespace membership is flawed.
The central point of Open VSX is who published an extension version and if a publisher agreement is active.

If you are member of a namespace, other people might have published the extensions (that are not member anymore), so deleting these extensions is just wrong if they have not been published by the user to forget.

Also, the PR implies that the publisher agreement shall be revoked, if that is the case, all extensions the user published also have to be deactivated / deleted to keep the invariant of the registry (only extensions with active publisher agreement are accessible)

Adds a GDPR endpoint to the OpenVSX API that allows for admin level tokens to request for users to be forgotten. Rather than deleting users, this request will scrub all PII from the existing user records to erase any potential leak of private information. This is done to best retain things like reviews and other user actions within the system while abiding by GDPR requirements. These deletion requests do not remove or modify any of the internal logging that already exists as there is a business need to retain that type of data, which will have it's own retention policy that will eventually purge those records. Assisted-by: Claude Sonnet 4.6

Based on feedback from Thomas N, the behaviour to deactivate extension versions in owned namespaces switched to instead delete versions published by the removed user. This is more inline with legal requirements as the removal of the Open VSX PA would revoke our right to publish the versions by the user.

autumnfound · 2026-07-30T19:28:05Z

Change has been rebased and logic for the extension version removal has been updated. It now checks for active + inactive extension versions by the user and does the delete functionality on them.

Still outstanding from feedback:

Admin delete via UI endpoint, we need to decide if we will keep or not (I think there's value, and I can easily add a button for it in the UI if needed)
Publisher revoke step has been retained. I think for the direction we're going w/ the project, keeping this step in is the right way to do it. External systems may or may not know about the PA in the future, and we shouldn't assume it can remove them.

autumnfound requested review from cstamas and netomi July 21, 2026 18:06

autumnfound force-pushed the malowe/main/ovsxorg-8200 branch from 7e2099c to 9ac5923 Compare July 21, 2026 18:38

netomi reviewed Jul 30, 2026

View reviewed changes

netomi mentioned this pull request Jul 30, 2026

Add Open VSX to the “Right to Be Forgotten” Automation Process EclipseFdn/open-vsx.org#8200

Open

autumnfound added 3 commits July 30, 2026 09:58

fix: Switch GDPR to use username instead of authId for ease of use

d4df729

autumnfound force-pushed the malowe/main/ovsxorg-8200 branch from 9ac5923 to 421ca3e Compare July 30, 2026 19:24

Uh oh!

Conversation

autumnfound commented Jul 21, 2026

Uh oh!

autumnfound commented Jul 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

netomi commented Jul 30, 2026

Uh oh!

autumnfound commented Jul 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants