feat: initial implementation of extension malware check

[shellz-n-stuff]

Description

Goose users need to install extensions in order to get the full utility they desire. However, our stdio MCPs are quite often coming from package ecosystems that can contain malware.

Though it's not possible to completely protect users from all forms of Malware (and other Supply Chain Attacks) implementing some basic checks for known bad packages better protects all Goose users! ❤️

Implementation

When a user attempts to activate an extension we will parse out the name of the package and/or version information (where possible) and attempt to query the OSV API to understand if the package contains malware (identified by MAL in the formatting).

If the http call fails for some reason and/or we have issues parsing we opt to fail open to ensure this doesn't present a disruption to users.

Note: This implementation only supports PyPi and NPM as package manager formats

Handling of non-provided package versions

One key choice here was we @latest syntax and no version provided syntax by checking if any version of the package has malware. Broadly speaking it's going to be rare that an extension is compromised, malware finding filed and then persisted on those versions but it "could" happen and I'm open to adjusting the approach if we have major upfront concerns

OSV/Malicious Packages

The OSV project contains vulnerability information and malware information for open-source packages. The Malware information is populated via https://github.com/ossf/malicious-packages and broadly is a trustworthy datasource.

Though OSV does contain vulnerability data we're strictly only checking for Malware in this case. We could potentially inform users of CVEs in the future using this interface but we'd want to make the product interface there much easier to understand for all users!

Testing

• Adding innocuous package that will be flagged as Malware

• Error is thrown and available in UI

• Clear error message

[shellz-n-stuff]

This was an idea from Goose. But I actually really liked it! Just in-case the OSV team want to identify us and/or hit us up

[tomasz-sq]

Thoughts on adding reasonable timeouts to prevent hanging on slow/unresponsive OSV API?

[tomasz-sq]

should we consider making the error more actionable? I was curious how to deal with false positives. Looks like the recommended way is to create a GH issue
https://github.com/ossf/malicious-packages/blob/main/README.md#false-positives