Registry keys being read by default

[FrankReh]

Just built wac from main with the command cargo install --path . and used it, with the plug subcommand, as a replacement for the wasm-tools compose command.

When running the binary, my macOS asked me if I wanted to grant access to my wa.dev keyring info.

Thing is, there are no references to wa.dev in the Wasm components that were being used as the inputs.

The command still worked and produced the desired output, even when I disallowed access to the keyring info, I think showing it wasn't necessary.

I had not provided the --registry command line option, so it seems it was trying to follow its default value.

[lann]

I suspect this will ultimately need to be fixed in https://github.com/bytecodealliance/registry

@calvinrp

[calvinrp]

If you use the wac plug subcommand with only local file paths, it shouldn't try to check the registry for anything.

If you use a registry package name instead of a local file path, such as my-namespace:package-name@0.1.0 (version optional), then it will try to use your global Warg configuration (if available). If you override the registry URL with --registry, it will use that instead of your global Warg configured registry.

The keyring unlock is expected for a different binary having access to your auth token that you may have configured with wa.dev Warg setup. If granted, then you are authenticated. If the packages are public, you don't have to use authentication.

The global / local config problem is confusing (and not great) and under active discussion:
bytecodealliance/wasm-pkg-tools#10
bytecodealliance/wasm-pkg-tools#3

@FrankReh If you'd like the wac registry behavior or messaging changed, please let me know.

[calvinrp]

After further investigation, there is a bug and the Warg client needs to be lazily instantiated. Following up with a PR.

[calvinrp]

Fixed in #110