Alter extension warning for `super_user`

[filiptronicek]

trafficstars

When one goes to an extension page published by a user who isn't the verified publisher of a namespace, you get this scary warning message:

I like the banner, it is awesome for motivating authors to verify their namespaces and make Open VSX a better marketplace for all. I think putting it everywhere is a bit too much though, because:

1. Companies such as Microsoft will never publish to Open VSX, so it would be better to remove this banner for these ones, because I don't think it's a good thing our biggest extension, ms-python.python, is filled with warnings.
2. The super_user account (@open-vsx for open-vsx.org) only publishes extensions which are reviewed by me and the team to make sure we aren't publishing some malicious fork. It's only open-source extensions and our extensions manifest is transparent about that.

I'd love to start a discussion about this here and would love to hear any ideas 😃.

[filiptronicek]

This issue was motivated by a message from way back on December 20th, 2021, when I posted the following in our Gitpod Slack:

We could (maybe should) make a custom warning for extensions published by the service account to maybe let people know that the extension at hand is updated automatically (and make it less scary in this case)? This big orange warning is shown on all of the extensions published from open-vsx/publish-extensions, including the biggest extensions on OpenVSX like the Python extension by Microsoft (all Microsoft extensions apply)

[amvanbaren]

We could only show the orange warning banner if the logged in user is the publisher of the extension, so that they can take action to get their extension verified.

Other users will only see the warning icon next to ms-python.python ({namespace}.{extension}). I think that would look way less scary.

[amvanbaren]

Maybe add a new publisher category, e.g. 'trusted reposter'?

[filiptronicek]

@amvanbaren thanks a lot for the suggestions 🙏. Here are my thoughts:

Other users will only see the warning icon next to ms-python.python ({namespace}.{extension}). I think that would look way less scary.

That's a really great idea! I like it, but, thinking about it more it probably won't be that much of a help. I am worried mainly because I think most extensions, which are not verified and published by @open-vsx are not aware of Open VSX / if they are, they most likely don't have an account, since that is mostly only useful for publishing -> the authors that should be worried about this and have the banner shown to them aren't probably registered on ovsx. Not sure what to do about this, it's a tough one 😕.

Maybe add a new publisher category, e.g. 'trusted reposter'?

We could do that, do you think we should add users to the category who are publishing as a third party? Do these accounts exist apart from @open-vsx?

[amvanbaren]

Do these accounts exist apart from @open-vsx?

I don't know. My guess is that the @open-vsx user is the same as the super_user account on dev.

It's probably easier to let the @open-vsx user claim all the namespaces it's publishing to, because in most cases that namespace will not be claimed anyway. In the event that the namespace does get claimed by the actual publisher, then the namespace gets granted to the publisher. The downside is that the published_by field still says @open-vsx instead of the new publisher's name.

Whether a publisher is verified or not will be determined by domain verification instead: https://github.com/eclipse/openvsx/issues/453

[filiptronicek]

@amvanbaren it seems to me that the behavior of extensions being marked as "unverified" is not to be expected in most cases on extensions published by @open-vsx. This is stated on the Namespace Access page of the Wiki [1]. It should be only shown if "the namespace was owned by someone else", which usually isn't the case.

Because of this, I think all namespaces should not be claimed by the service account, but rather shown as verified in the UI. It would be unfortunate to see the publisher stuck on this service account when we talk to maintainers and they begin publishing themselves. Could we have those just verified in the UI?

Whether a publisher is verified or not will be determined by domain verification instead

Is this final? I have some thoughts on this, which I'll leave here, since the mentioned issue seems to be about the feature itself:

1. I believe this would be a good addition to have verifiable domains to show inside of VS Code and in the web UI.

2. I do not think we should replace our current verification process: we require publishers to prove they are the ones responsible for publishing the extension. I see it as two different types of verification: a. Domain verification indicates whether the extension is one which is published by folks over at e.g. google.com or github.com [company X is behind this extension]. b. User verification indicates whether the extension is one which is published by the people working on the extension [this is really the extension I'm expecting, published by someone involved with it].

3. If this change took place, would that mean that all verified publishers would suddenly be unverified? I'm scared about this being way more involving of a process for publishers -> we lose a lot of verified namespaces.

[amvanbaren]

@filiptronicek When a namespace is created, the user that issued the command becomes a contributor to the namespace. https://github.com/eclipse/openvsx/blob/df28c16c4d919afaf1c8795ab0dfabd842ceb6e6/server/src/main/java/org/eclipse/openvsx/LocalRegistryService.java#L436-L446

Once the namespace has been created, you need to be a member of that namespace to be able to publish to it. https://github.com/eclipse/openvsx/blob/df28c16c4d919afaf1c8795ab0dfabd842ceb6e6/server/src/main/java/org/eclipse/openvsx/ExtensionService.java#L94-L96 https://github.com/eclipse/openvsx/blob/df28c16c4d919afaf1c8795ab0dfabd842ceb6e6/server/src/main/java/org/eclipse/openvsx/UserService.java#L126-L140

This means that every namespace that @open-vsx is currently publishing to as a contributor has to be claimed by the actual publisher by opening an issue in the https://github.com/EclipseFdn/open-vsx.org/ repository before they can start publishing. You might as well make @open-vsx the owner of the namespace and once the namespace gets claimed by the actual publisher either demote @open-vsx to contributor or remove it as a namespace member.

Is this final?

No, this is far from final. I don't know how the current publisher verification and the new domain verification should relate to each other. Like you pointed out, they don't have to be mutually exclusive. Although having two badges/checkmarks in the web UI might be a bit confusing. @jeanp413 What do you think?

[filiptronicek]

Thanks for sharing the links and comments, @amvanbaren!

This means that every namespace that @open-vsx is currently publishing to as a contributor has to be claimed

Does that mean that @open-vsx is a contributor to all namespaces on open-vsx.org? I think it would be ideal if we found a solution which satisfies these points:

• when the maintainers request the namespace and start publishing, their name is displayed as the publisher
• @open-vsx is a "verified publisher" of all extensions it publishes
• @open-vsx can publish to any namespace even after it is taken over by a publisher

Would your proposed solution with @open-vsx owning the namespaces at first (and then being demoted to contributor) work with these three?

[amvanbaren]

Does that mean that @open-vsx is a contributor to all namespaces on open-vsx.org?

No, @open-vsx is only a contributor to all namespaces it created. It can publish to all other namespaces, because it's a privileged user.

Would your proposed solution with @open-vsx owning the namespaces at first (and then being demoted to contributor) work with these three?

• when the maintainers request the namespace and start publishing, their name is displayed as the publisher.

For the new versions they publish their name is displayed as the publisher, but when a user goes back to a previous version then @open-vsx is displayed as the publisher. @open-vsx has to stay a contributor, because else the previous versions, published by @open-vsx, become unverified.

• @open-vsx is a "verified publisher" of all extensions it publishes.

Making @open-vsx the owner of a namespace will verify the extension versions it publishes to the namespace. However, when @open-vsx publishes to a namespace using its privileged role and the namespace doesn't have an owner and @open-vsx is not a member of the namespace (owner or contributor), then the published extension version is unverified.

We can add a condition to isVerified where if the user is a privileged user, then it's always verfied. https://github.com/eclipse/openvsx/blob/df28c16c4d919afaf1c8795ab0dfabd842ceb6e6/server/src/main/java/org/eclipse/openvsx/LocalRegistryService.java#L704-L722

• @open-vsx can publish to any namespace even after it is taken over by a publisher.

Yes, @open-vsx is a privileged user. From Namespace Access: "However, in case a namespace owner does not continue publishing an extension that is relevant to the community, this extensions can be put back to the list, and @open-vsx will publish it even if it is not a member of its namespace. This is an exclusive privilege of the @open-vsx account, and of course it should be used sparingly."

[amvanbaren]

From Namespace Access:

A warning icon ⚠️ is shown for some extensions, along with a hint that the publishing user is not verified. There are multiple situations that can cause this warning.

• A user created the namespace and published the extension, but did not claim ownership of the namespace.
• A user published the extension, but is no longer a member of the namespace (they were removed by an owner).
• The extension was published by the privileged @open-vsx account although the namespace was owned by someone else.

The last bullet point says that only if the namespace was owned by someone else, then a version published by @open-vsx should be marked as unverified. The isVerified methods don't check for this condition.

[jeanp413]

We can add a condition to isVerified where if the user is a privileged user, then it's always verfied.

I'll like this idea, as it's simple :+1: , I think playing with namespace ownership will add too complexity and bugs

[amvanbaren]

• [X] Add a condition to isVerified where if the user is a privileged user, then it's always verfied.
• [ ] Update Namespace Access to reflect the change in the code.