feat: authenticating when using remote archive

[matoous]

Note

Work in progress PR, opening early to collect feedback.

Add auth-token option to the CLI that allows configuring authentication when fetching registry from a remote archive.

Notes

auth-token is passed and handled separately from the virtual directory path string as the usual @ character separating userinfo portion of the URL from the host is reserved for the refspec. Taking the token from the userinfo portion of the URL would be an alternative to the approach in this commit but would make the parsing a little bit more cumbersome. I am open to both approach and happy to adjust the code to whatever the OpenTelemetry team deems better.

Open for discussion

• I am not sure what the real-world distribution of hosts of remote registries will be and if we can safely assume Bearer scheme in the Authorization header. For example, most guides using GitHub PATs use token scheme (even though Bearer works too). Using Bearer might be an OK compromise for the initial version.
• Registries can rely on further dependencies which in turn might again be private. In such scenario option for an approach with the token being part of the URL might not work as one wouldn't want to put their access token into the registry manifest. In such the proposed approach in this PR would work as long as all dependencies are hosted by the same remote and can be access with the same token. This might become irrelevant with e.g. Proposal: Introduce bundles #871 or similar bundling approach.

---

Fixes: #430

[jsuereth]

Apologies for taking a while to get to this. My thoughts are:

• Whatever auth we support, ideally, we'd keep it similar to curl from a command line perspective.
• If we wanted deeper configuration, that should be done via ~/weaver.yml or ~/.weaver/weaver.yml.
• We can evolve our support over time based on need. Priority wise I think:
  • Supporting Github resolution should be top priority
  • General purpose (but possibly awkward bearer-token) should ALSO exist for fallback / other cases.
  • Further auth models we can evaluate on an as-needed basis.

@lquerel is best to review any configuration options / auth model here for multi-registry support.

[matoous]

Heya! Thanks for the feedback, minor note on one of the bullet points:

Whatever auth we support, ideally, we'd keep it similar to curl from a command line perspective.

We can do that for basic auth with username:password, otherwise to use Bearer authorization scheme in curl one would do -H "Authorization: Bearer XXX" and I am not sure if it would make sense to support arbitrary headers in weaver? No strong opinions though.

[jsuereth]

Heya! Thanks for the feedback, minor note on one of the bullet points:

Whatever auth we support, ideally, we'd keep it similar to curl from a command line perspective.

We can do that for basic auth with username:password, otherwise to use Bearer authorization scheme in curl one would do -H "Authorization: Bearer XXX" and I am not sure if it would make sense to support arbitrary headers in weaver? No strong opinions though.

Fair point. yes we could limit to just the authorization header. However, it may also make sense to have extensible headers so we're "future proof" there. I'd like @lquerel's thoughts