Add support for the VSIX / Visual Studio Marketplace ecosystem#357
Add support for the VSIX / Visual Studio Marketplace ecosystem#357another-rex merged 3 commits intoossf:mainfrom
Conversation
|
hey, sorry for the delay in getting back on this! Are there any contacts for the Visual Studio Marketplace ecosystem we could involve here to make sure we have the definitions right? |
|
We're not currently in contact with anyone, but some time ago I mentioned VSX to @calebbrown, with regards to malicious packages, and I recall him saying that he knows people there. I'm also hoping to push our VSX PURL specification to the official purl-spec, to also have that available. |
docs/schema.md
Outdated
| | `SUSE` | The SUSE ecosystem; The ecosystem string has a `:<RELEASE>` suffix representing the marketing name of the SUSE product. `<RELEASE>` matches the value in the /etc/os-release `PRETTY_NAME` field. The `name` field is the name of the source RPM and accompanied by a purl. There is a `ecosystem_specific` specific array `binaries` of the associated RPM binary packages in this specific SUSE product. The ECOSYSTEM version ordering is the RPM versioncompare ordering, and the database uses the `introduced` and `fixed` boundaries. | | ||
| | `SwiftURL` | The Swift Package Manager ecosystem. The `name` is a Git URL to the source of the package. Versions are Git tags that comform to [SemVer 2.0](https://docs.swift.org/package-manager/PackageDescription/PackageDescription.html#version). | | ||
| | `Ubuntu` | The Ubuntu package ecosystem; the `name` field is the name of the source package. The ecosystem string has a `:<RELEASE>` suffix to scope the package to a particular Ubuntu release. `<RELEASE>` is a numeric ("YY.MM") version as specified in [Ubuntu Releases](https://wiki.ubuntu.com/Releases), with a mandatory `:LTS` suffix if the release is marked as LTS. The release version may also be prefixed with `:Pro:` to denote Ubuntu Pro (aka Expanded Security Maintenance (ESM)) updates. For example, the ecosystem string "Ubuntu:22.04:LTS" refers to Ubuntu 22.04 LTS (jammy), while "Ubuntu:Pro:18.04:LTS" refers to fixes that landed in Ubuntu 18.04 LTS (bionic) under Ubuntu Pro/ESM. | | ||
| | `Visual Studio Marketplace` | The Visual Studio Marketplace package ecosystem; the `name` field is the name of the extension prefixed by the publisher name, which creates a unique identifier for the package. | |
There was a problem hiding this comment.
Please clarify this further.
I think the name should match the itemName of the extension, e.g. for https://marketplace.visualstudio.com/items?itemName=Mend.mend-vs2022, it would be Mend.mend-vs2022 therefore the prefixing would be separated by a period?
There was a problem hiding this comment.
Sorry for the delay! I had to double check a few things to give a definite answer. So yes, the itemName is what seems to constitute a unique identifier for a VS Marketplace package, but these are in essence constructed from publisher.id from the Identity field of the manifest.
I've also omitted to mention that these are case insensitive, e.g.
https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools
https://marketplace.visualstudio.com/items?itemName=ms-vscode.CMake-tools
lead to the same thing. But as far as I'm aware the name (and version) field in OSV is not considered normalized; we use PURLs everywhere for our malware advisories to construct a unique identifier (VSIX does not have a PURL in the spec though, but we plan to propose one).
There was a problem hiding this comment.
Update; this seems to hold true for extensions that aren't Visual Studio ones, however for example
https://marketplace.visualstudio.com/items?itemName=SharpDevelopTeam.ILSpy2022
and other Visual Studio extensions hold a GUID for the internal Id of an extension, in the manifest:
<Identity Id="ebf12ca7-a1fd-4aee-a894-4a0c5682fc2f" Version="9.1.0.7988" Language="en-US" Publisher="SharpDevelop Team" />
I'm not sure how they construct the itemName it this case, but it seems they just normalize the display name slightly? This does throw a kink into it, since the unique identifier would probably be the GUID found in the manifest, it seems our internal PURL implementation does just that, to be consistent in its construction.
It's e.g. pkg:vsx/ms-vscode.cmake-tools@1.21.36 for the VS Code extensions but
pkg:vsx/sharpdevelop%20team/ebf12ca7-a1fd-4aee-a894-4a0c5682fc2f@9.1.0.7988 for a VS extension.
There was a problem hiding this comment.
I wonder if vscode extensions and vs extensions should be two separate ecosystems, as the entire format of the manifest is completely different, which makes it hard to define here. I think we should focus on the vscode marketplace here, and define the name to be Publisher.Id as found in the vsixmanifest. (Which matches the itemName in the url.
There was a problem hiding this comment.
With that change, we should probably rename the ecosystem to VS Code Extensions or something similar.
There was a problem hiding this comment.
Hey, I participated in the vsx / vscode PURL spec discussion as well, and we kind of came to the same conclusion there
package-url/purl-spec#673 (comment)
So I do agree that's the way to go here as well, I'll give a couple of suggestions.
I think we should be able to validate the PR in its current form from first principles, if we can't identify appropriate points of contact at Microsoft. @rhalar could you please address the DCO check failure? |
|
Ping! @another-rex @michaelkedar Thanks @rhalar for pushing this, the need for this seems to be growing - particularly for Malicious Packages. Would the current implementation also support non-Microsoft marketplaces like Eclipse's OpenVSX? |
|
If we define the name as the Publisher.Id field inside the vsix manifest, and limit it only to VS Code extension (not VS extensions), then I believe yes it would support both. The only issue is if there is a case where both market places publishes different packages with the same publisher, name, and version. But if that happens we can't distinguish that when extracting the extension either, so I don't think it's a big issue. |
The new PURLs |
another-rex
left a comment
There was a problem hiding this comment.
LGTM! @andrewpollock can you take another look as well?
|
Please also run |
556467b to
6b6e534
Compare
Signed-off-by: rhalar <robert.halar@reversinglabs.com>
Signed-off-by: rhalar <robert.halar@reversinglabs.com>
6b6e534 to
248aa3d
Compare
Updated the ecosystem.json file and ran the update-ecosystems-lists.py script Signed-off-by: rhalar <robert.halar@reversinglabs.com>
248aa3d to
8224644
Compare
Includes: * 1.6.6: ossf/osv-schema#276 * 1.6.7: nothing * 1.7.0: ossf/osv-schema#312 ossf/osv-schema#319 ossf/osv-schema#337 * 1.7.1: nothing * 1.7.2: ossf/osv-schema#351 ossf/osv-schema#347 ossf/osv-schema#358 * 1.7.3: ossf/osv-schema#394 * 1.7.4: ossf/osv-schema#434 ossf/osv-schema#357
Includes: * 1.6.6: ossf/osv-schema#276 * 1.6.7: nothing * 1.7.0: ossf/osv-schema#312 ossf/osv-schema#319 ossf/osv-schema#337 * 1.7.1: nothing * 1.7.2: ossf/osv-schema#351 ossf/osv-schema#347 ossf/osv-schema#358 * 1.7.3: ossf/osv-schema#394 * 1.7.4: ossf/osv-schema#434 ossf/osv-schema#357
Includes: * 1.7.0: ossf/osv-schema#312 (`upstream` field) ossf/osv-schema#319 ossf/osv-schema#337 (`Ubuntu` as `severity` score) * 1.7.1: nothing * 1.7.2: ossf/osv-schema#351 ossf/osv-schema#347 ossf/osv-schema#358 * 1.7.3: ossf/osv-schema#394 * 1.7.4: ossf/osv-schema#434 ossf/osv-schema#357
Includes: * 1.7.0: * ossf/osv-schema#312 (`upstream` field) * ossf/osv-schema#319 * ossf/osv-schema#337 (`Ubuntu` as `severity` score) * 1.7.1: nothing * 1.7.2: * ossf/osv-schema#351 * ossf/osv-schema#347 * ossf/osv-schema#358 * 1.7.3: * ossf/osv-schema#394 * 1.7.4: ossf/osv-schema#434 * ossf/osv-schema#357
We're contributors to the OSSF Malicious Package repository; we'd like to add our findings for VSIX packages but we're missing the appropriate ecosystem in the schema.
We'd propose adding a
VSIXecosystem, or perhapsVisual Studio Marketplacewould be more accurate? The name is a bit chunky soVS Marketplacecould also work, we're open to ideas and suggestions.There aren't any VS(C) extension vulnerability advisories as far as we're aware so that would only be a ecosystem addition for use in malicious advisories on the OSSF, if that is not objectionable.
A few examples of such malicious extensions
https://www.reversinglabs.com/blog/malicious-helpers-vs-code-extensions-observed-stealing-sensitive-information
https://x.com/ReversingLabs/status/1902355039265411208