add OpenVSX

[mixmix]

OpenVSX is an open-source registry Extensions to VS Code Compatible Editors.

This PR adds support which takes into account extension naming patterns, along with ability to specify platform for some extensions which have platform-specific builds of extensions.

[jkowalleck]

there is a concurrent proposal: #673

[booniepepper]

Is there any difference between an extension published to open-vsx.org and one published to the Microsoft store? I've been able to publish the same .vsix distribution to both without needing any changes. I'm not aware of any difference beyond the onboarding & agreements

[pohlarized]

Given your comment in #673 about naming, i think the important part is that they can be different.
So i'd say there definitely has to be a distinction between openvsx and the microsoft store.
I think like with e.g. pypi or npm, the types mostly reference the registry where the concrete artifacts live, not just the kind of package it is.
There is also e.g. deb or rpm where you have an extra qualifier to indicate the concrete distro, but there they still live in the same repo structure, whereas openvsx and the microsoft extension store are two completely distinct entities.

[booniepepper]

I disagree that a repository justifies a unique identifier.

The names for pypi/npm packages in the PURL spec do derive from the first major packaging project and repository in their ecosystem... (and so do many others) but we still consider artifacts as pypi/npm packages in the PURL spec when they come from other repositories but still follow the same package format and protocol. E.g. a typescript module in JSR will still be considered an npm package, and use the repository_url to distinguish origin. The same goes for packages in other places like GitHub Packages, Artifactory, AWS CodeArtifact, CloudSmith, Google Cloud Artifact Registry, other public/private repositories. The same goes for other packaging protocols like maven etc.

Am I missing something that makes these more distinct? Packages seem the same, and the protocol seems to be simply downloading the package from a URL

[pohlarized]

Yes, sorry, i guess you're right. From the naming of some of the types, and the goal to uniquely identify a package i wrongfully concluded that the repository should be the important identifier (since within different registries, the same package identifier may lead to different packages, even if the registries use the same protocol). But especially with the example given in e.g. the maven spec, it does seem like it really is more about the protocol.
Though i guess the discussion about this does not belong into this PR.

Sorry for the confusion!

[mixmix]

I strongly believe the registry needs to be an important consideration, but perhaps we need to check in on the intention of PURL specs for that to be a productive conversation. Checking the README of this repo:

When tools, APIs and databases process or store multiple package types, it is difficult to reference the same software package across tools in a uniform way.

The tension I'm feeling is if we do something like pkg:vscode/namespace.extension@1.2.3, then I want to know that if I refer to that and use that as a "key" to access "that code", that I get the same code. If we have one purl for vs-code marketplace AND open-vsx, that guarentee is broken. It's broken because there is AFAIK no guarantee that an extension with the same name + version is the same on those two registries. This is because the registries host code in different places, may actually have different authors, and in the worst case the code may be radically different and be a malicious attack.

I see two possible paths forward to resolve that tension (and am open to hearing more):
(edited for formatting consistency)

1. PURLs are registry bound

e.g. pkg:openvsx AND pkg:vscode both exist

2. Add a hash to the PURL

e.g. with a hash `pkg:vsx/namespace.extension/hash@1.2.3

---

I'm worried about (2) because I think it's gonna be super ugly, and there might be pressure to make that security optional, or "lite", like making the hash optional, or "only the first 6 char of the hash". I know openvsx stores a hash, I wonder if microsoft does (yay undocumented APIs)

[booniepepper]

I think I agree with @mixmix in the PR that the namespace maps best to publisher, and this is more consistent with namespaces in most PURL types.

The apt/deb/rpm types I think are outliers, and vscode extensions are more similar to other types. One other note is that in some of those OS packaging ecosystems, they are similar enough to be grouped together, but are not drop-in compatible. Try subscribing to an Ubuntu PPA from Debian and trying to install the deb, it blows up pretty fast. In the VS Code extension case, as far as I know, I can install vsix extensions from both registries and they are drop-in compatible.

The sad reality is that most security tooling doesn't use repository_url where it should

That sounds like a failing of tooling, not the spec. If tooling is being told an artifact came from a specific URL and it's doing something insane like discarding that information, that does not sound like security tooling to me

[pohlarized]

I agree with the idea that purls should be unique identifiers of packages, with ideally no way to accidentally have two different interpretations which package it references. But i would also agree with @booniepepper that for the current state of the spec, this is not the case for many purl types. I would thus say, that thinking about how to make purls more unique is a broader discussion that does not have to happen in here, and should not be a blocker for the PR, but that should definitely happen somewhere.

I don't think that namespaces are semantically fit to make the distinction between the two registries, i would say that the repository_url is indeed the most fitting place right now. It is true that this could be a little misleading since the default is implicit (and i guess it would point at the microsoft store), but again, it feels very in line with the current state of the spec.

[booniepepper]

That's the approach I used in my PR

Also, just to restate it in other words... pkg:etc@1.2.3 and pkg:etc@1.2.3?repository_url=some.cool.url are already distinct and unique identifiers. I don't believe this is misleading or insufficient, and the various PURL specs define default url where appropriate from what I've seen.

[matt-phylum]

Using different repository_url qualifiers creates distinct PURLs, and that's how it normally works for other types. Using a namespace component instead would require defining all the possible namespaces (impossible because anybody can create their own) and PURL implementations would need to include mapping logic to convert to/from the namespace values.

[mixmix]

While the plugins are drop-in, I think it makes most sense to close this PR and proceed with @booniepepper's #673

It's great to find a community that's up for exploring the options and finding the best solution - thanks everyone for the input and care 🥰