Create API Endpoint to Bulk Revoke Publishers

[JoeTot]

Overview

Description

Currently, revoking a malicious publisher is a purely manual process executed through the Open VSX Admin UI. During coordinated mass malware attacks, this manual workflow creates a severe bottleneck, increasing the Mean Time to Remediate (MTTR).

We need a secure, scriptable API endpoint to programmatically revoke publishers in bulk. Additionally, this endpoint must trigger an updated core revocation logic that completely severs the relationship between the revoked publisher and its claimed namespace(s).

Acceptance Criteria

• Endpoint Creation: Implement a new REST endpoint (e.g., POST /api/admin/publishers/revoke or DELETE /api/admin/publishers).
• Bulk Processing: The endpoint must accept a JSON payload containing an array of GitHub IDs and/or Publisher IDs to process in a single request.
• Namespace Severance: The revocation logic triggered by this endpoint must delete the mapping/association between the revoked publisher and any namespaces it owns.
• Security: The endpoint must be secured with strict Admin-only authorization, requiring an admin-scoped access token.
• Audit Logging: Every call to this endpoint must write to the audit log, capturing:
  • Timestamp
  • Executing Admin/Service Account ID
  • List of target IDs
  • Action reason (required in payload)
• Response Handling: Return a structured response indicating which IDs were successfully revoked and which failed (e.g., 404 Not Found).

cc @kineticsquid

[kineticsquid]

@JoeTot This is a good write up. The only other thing to consider is if we could also integrate the deletion of the associated Eclipse Foundation ID. We can get that easily with this API call, https://api.eclipse.org/github/profile/{GH ID}. @ericpoirier is working on an API and UI for this. The challenge will be, I think, removing the EF ID requires an EF authentication in addition to the Open VSX Admin credentials.

[ericpoirier]

@kineticsquid @JoeTot to clarify what I worked on is a UI form to let admins block users by Eclipse username. I haven't implemented any API for this.

[autumnfound]

Potential implementation notes

2 new API endpoints under the Admin section will be created. The first is an API meant to be bound to the front-end Admin Dashboard for manual bulk action, with the second being an API meant to be used with admin level API access tokens. While these APIs will have different paths and authentication mechanisms, they will call the same underlying functionality. These endpoints will accept a JSON object like the below object. There will be a hard limit of 25 publishers per request to ensure that the server and return in a timely fashion.

{
    "publishers": [
        {
            "provider": "github|eclipse",
            "loginName": "autumnfound",    
        }
    ],
    "reason": "Message to include in the audit item saved to the database",
}

The publishers passed in the publishers property will then be passed directly into the existing logic for revoking publishers. This process will take the following actions:

• Revoke the users Publisher Agreement
• Revoke all active access tokens
• Deactivate all extension versions published by the user
• Create an Audit log record for the user

These requests will all happen synchronously at request time and be returned to the user as a JSON body reporting the status of each user, either including the success message about the deactivated publisher or an error message to indicate why the request passed or failed. Status of the users' revocation will be by the presence of either a success or error message in the response object, with a sample included below.

{
    "statuses": {
        "autumnfound": {
            "success|error": "Message about the status of the request"
        }
    }
}

Additionally, a new facet of the Admin Dashboard will need to be created that creates a GUI for simplified access outside of direct API access. This will have client side validation to ensure that the limit is obeyed, and will allow for users to be searched by their GitHub loginName. While we can also support passing loginNames associated with other providers, we should keep the admin dashboard to the commonly used loginNames for simplicity sake.

Points of clarification

For the currently existing revocation process we don't break the link between namespaces and the publisher. Do we want to add this to the existing revocation logic? I'd imagine being consistent with how we handle user revocation actions will make it easier to manage these users and their state.

Additionally, do we want any kind of guardrails for this request? I'm thinking the simplest one at the very least that we ensure that an admin doesn't revoke themselves, but do we want to also stop admins from being revoked/removed by this process?

[autumnfound]

This is a good write up. The only other thing to consider is if we could also integrate the deletion of the associated Eclipse Foundation ID.

@kineticsquid that will be handled outside of the open-source project, as it's something that is an Eclipse Foundation specific use case that no other adopter of the project would have any use for and isn't something we'd want them to be able to do. We do have an internal task to take care of this as a side effect of revoking the publisher agreement!

Additionally @JoeTot @kineticsquid I have another question on top of the 2 listed above. For the updates to revocation to include namespace relationship severing, do we want that to always happen when we revoke a publisher agreement? Are there cases where the revocation of a publisher agreement isn't due to malicious action and instead is part of some sort of general admin task? If we need to cover general admin tasks, I would add that we'd want some sort of flag on revocation operations to indicate the user is malicious and more severe actions should be taken.

[kineticsquid]

@autumnfound Yes, we want to remove the GH ID from any namespaces, either as a committer or owner. And yes, while IMO unlikely, I think we'd want to prohibit the removal of admin IDs. Make this an explicit manual process.

Answering your third question above. I think that question may intersect with actions we need to taken when a user changes their GitHub ID. There appears to be some magic that happens in the EF database that I am unfamiliar with. Just need to be sure we can cover this use case.

[autumnfound]

Answering your third question above. I think that question may intersect with actions we need to taken when a user changes their GitHub ID. There appears to be some magic that happens in the EF database that I am unfamiliar with. Just need to be sure we can cover this use case.

There definitely needs to be some handling for updating a GH ID. Right now the OpenVSX API doesn't handle it in a robust way, so I think that can be taken into consideration outside of the scope of this issue. What we can do in the meantime is ensure that there is a non-destructive revocation path so that these sorts of operations are easier to resolve.