wapm-cli VS cli

To actually compile this we can use a tool called WABT (WebAssembly Binary Toolkit). It's basically a mess that requires CMake and I couldn't get it to run on WSL and I wasn't going to install MinGW. Instead there's a nice tool called WAPM from Wasmer which works like npm for webassembly packages and since it's been compiled down to webassembly we can run it in any environment. In fact we don't even need to add configuration so long as wapm is installed. We can run wax wat2wasm -- wat/mat.wat -o wasm/mat.wasm. wax is like npx for npm. If you're wondering the command we give wax is defined by the wasmer/wabt package: https://wapm.io/wasmer/wabt. Also for some reason you can't prefix local paths with ./ so wax wat2wasm -- ./wat/mat.wat doesn't work which tool me a while to figure out. Anyway this provides a nice simple compile environment if you want to work on raw WAT files.

That's the main reason we should start using WebAssembly for distributing and using packages.

Shamless plug: Wasmer [1] and WAPM [2] could help a lot on this quest!

[1]: https://wasmer.io/

[2]: https://wapm.io/

There's WAPM

If it's buildable for the WebAssembly WASI target, consider also distributing it through WAPM.

I don't know if many people have heard of it, but there's actually a WebAssembly Package Manager. It's similar to crates.io, except you upload WebAssembly binaries written in any language instead of Rust source code!

You can see this paying off with wapm, which lets you download applications that would have normally required compilation for your environment and run them anywhere with a supported runtime, which is imo pretty neat.

One step closer to the day when I can put actix-web creations up on WAPM so "Just type wax my-cool-thing to try it out" can be one of the distribution options.

I've added limited support to run wapm.io directly from the Terminal. Examples of commands that work well are wapm cowsay {Text} and wapm uuid.

Co-funder @ Phylum here (https://phylum.io) We have been actively scanning dependencies across npm (and PyPI, RubyGems, Crates.io, etc.) for nearly three years now; quite successfully, I might add (https://blog.phylum.io/tag/research/). We _automatically_ hit on this package when it was published, and our research team has been all over it.

A collective of us are active in Discord (https://discord.gg/Fe6pr5eW6p), continuing to hunt attacks like these. If that's something that interests you, we'd love to have you!

In addition to this, we've released several open source tools to help protect against supply chain attacks:

1. https://github.com/phylum-dev/birdcage - Birdcage is a cross-platform embeddable sandbox that's been baked into our CLI (which wraps npm, pypi, etc.) to sandbox package installations

2. https://github.com/phylum-dev/cli - Our CLI provides an extension capability so you can lock down random executables you might use during your software development (define _what_ it's allowed to do, e.g. network access, and then lock it down with Birdcage)

We also have a variety of integrations, including Github, Gitlab, BitBucket, CircleCI, Tines, Sophos, etc.

https://docs.phylum.io/docs/integrations_overview

It's unfortunate that software dependency attacks continue to plague open source registries. It seems unlikely this will let up in the near future. We are continuing to work closely with the open source ecosystems to try and get these sorts of packages removed when they pop up.

We're actively working on this with our sandbox (https://github.com/phylum-dev/birdcage). We've wrapped the likes of pip, yarn, and npm already and are making moves to similarly provide support for cargo.

Currently comes as part of the Phylum CLI (https://github.com/phylum-dev/cli), so that doing something like:

    phylum npm install 

cli - uses sandbox to block packages during installation, performs pre-install checks to determine (by hitting the API) if the package performs actions congruent with malware, e.g. phylum pip install requests will use pip wrapped by the sandbox to install requests after verifying that it doesn't have malware like behavior.

This is bundled with our CLI tool today (which is also open source) and allows you to install packages with phylum npm install . We currently support npm, yarn and pip and are planning on rolling out further support for other ecosystems in coming months.

We open sourced our tooling to help with this problem specifically. We have an extension framework that wraps npm for three purposes:

Our CLI tool (also open source and free) will check for typosquats, dependency confusion, malicious code, vulnerabilities, etc. in your package dependencies. Works for pypi, npm, rubygems, maven, nuget and very recently golang and rust crates.

This is built into the Phylum CLI so you can do things like:

This is one of the projects we're working on (and open sourcing)!

Currently allows you to specify allowed resources during the package installation in a way very similar to what you've outlined [1].

The sandbox itself lives here [2] and can be integrated into other projects.

1. https://github.com/phylum-dev/cli/blob/main/extensions/npm/P...

2. https://github.com/phylum-dev/birdcage

We will start here with a slightly more in-depth, custom version of the existing NPM shim extension - a tool that enforces default project policy when installing NPM packages. This custom extension will do some additional custom validation before allowing the installation process to continue.