Add support for publishing private packages

[Michael-F-Bryan]

This updates the wasmer publish command to allow users to publish private packages. When a package is private, you will only be able to access it if you have contributor access (e.g. because you are the owner, have been added as a contributor, or are part of a namespace that owns the package).

[theduke]

One concern I have here is that we are duplicating the responsibility for marking a package as private.

Is it the private setting in wasmer.toml?
Is it the CLI flag and the GraphQL argument?

What happens when the GraphQL specifies private, but not the package manifest?
Will the backend alter the manifest before persisting it?

What happens on a re-publish when you forget the private flag?
Does the API return an error then because the package is private?
Does it just accept it?

This all sounds quite confusing from a user stand point.

It would be cleaner, I think, if the manifest was the source of truth.
An additional --private flag or the CLI arg could make sure the package is set to private in the manifest and error out. Similar for the GraphQL API.

Thoughts, @Michael-F-Bryan , @ayys ?

[ayys]

I agree that wasmer.toml should be the source of truth,

What happens when the GraphQL specifies private, but not the package manifest?

the graphql private field and CLI argument --private should still exist, but they will be validated against wasmer.toml. If the config file does not have private = true set, then the backend should throw an error.

What happens on a re-publish when you forget the private flag?

For visibility, right now piblic packages cannot be made private, but private packages can be made public. So if you remove the private = true field from the config, the package should become public (the CLI should confirm this change with the user?)

An additional --private flag or the CLI arg could make sure the package is set to private in the manifest and error out. Similar for the GraphQL API.

I agree that the private field for the CLI and for GraphQL should be there to make sure wasmer.toml has private = true set and then use that..

[Michael-F-Bryan]

@theduke this is my understanding. @ayys feel free to correct me if I'm wrong.

Is it the private setting in wasmer.toml?

Yep. We added a private flag to the [package] table in wasmerio/wasmer-toml#31 (released as wasmer-toml v0.9.1) and the webc crate also added support for it in https://github.com/wasmerio/pirita/pull/186 (released as webc v5.6.0).

It would be cleaner, I think, if the manifest was the source of truth.

100% agreed. It's traceable and immediately obvious to anyone consuming the packages.

What happens when the GraphQL specifies private, but not the package manifest?

If there is disagreement between the manifest and the GraphQL mutation, the backend should return an error and publishing will fail.

Will the backend alter the manifest before persisting it?

To the best of my knowledge, no. Altering the manifest that someone has published is something we should try to avoid as much as possible.

When I publish something, I want to be confident that my users get exactly what I published.

What happens on a re-publish when you forget the private flag?
Does the API return an error then because the package is private?
Does it just accept it?

@ayys probably knows better than me, but I think this would silently make the package public.

An additional --private flag or the CLI arg could make sure the package is set to private in the manifest and error out. Similar for the GraphQL API.

I'd like to avoid a --private flag if we can. It feels like we could confuse users by having a --private flag which doesn't actually mark the package as private, but instead acts as a sort of validation. It also leads to ambiguities over whether the wasmer.toml or --private is the way you should mark a package as private, a lot of people won't read docs and will instead check wasmer publish --help, so they'll probably see the --private flag first.