Publishing features to other registries than ghcr.io

[aacebedo]

Hi

I tried to publish a feature to a private repo on another package registry (gitlab) and it failed.
Seems that identification token is only handled for GH registries.

Is it confirmed? Is there some way to do this?

[samruddhikhandale]

Hi @aacebedo 👋

Does gitlab use an OCI registry? I believe the CLI currently supports only OCI.

@joshspicer could you help correct my statement if I'm missing something.

[Clockwork-Muse]

There's at least one issue asking them to support it, so I don't think they implement the distribution spec.

That said, I'm currently not able to publish to a private azure registry, although it appears that it should be possible to (I get the same error as for gitlab, so maybe not).

[Clockwork-Muse]

More concretely, what's failing is attempts to get login tokens to check for versions before publish (but after build/test/package). As near as I'm aware, there's no documentation around what's required to be able to upload to private/secured registries - and that you might need different credentials to do so (for instance if you have 2FA enabled, you likely need a credential helper to manage a token).

The cli is trying to get a token from {registry}/token:

• Azure has a (beta/preview) token endpoint at {registry}/oauth2/token
• gitlab has nothing.

[joshspicer]

@aacebedo - Yes, the registry needs to support the distribution spec (some registries are listed here: https://oras.land/implementors). Note that we only auto-detect the GITHUB_TOKEN for auth at the moment (work to

I recently merged a PR that exercises the CLI against the reference registry implementation (#318). It just went in so it's not released to npm, but you can build from source to play with it.

We have an undocumented mechanism to auth against other registries with an environment variable

cli/src/spec-configuration/containerCollectionsOCI.ts

Lines 262 to 270 in fd4de3f

	} else if (!!env['DEVCONTAINERS_OCI_AUTH']) {
	// eg: DEVCONTAINERS_OCI_AUTH=domain1|user1|token1,domain2|user2|token2
	const authContexts = env['DEVCONTAINERS_OCI_AUTH'].split(',');
	const authContext = authContexts.find(a => a.split('|')[0] === registry);
	if (authContext) {
	output.write(`Using match from DEVCONTAINERS_OCI_AUTH for registry '${registry}'`, LogLevel.Trace);
	const split = authContext.split('|');
	userToken = `${split[1]}:${split[2]}`;

We have an open work item to read in the local .docker/config.json for auth with other registries, but that work is still in flight.

[joshspicer]

@Clockwork-Muse yea, the /token api doesn't seem to be well documented in the spec (please let me know if eventually happen to find a spec for how that should be implemented!). The recent change I reference above will attempt to use the basic auth creds if it cannot fetch from the /token endpoint (which seems it may be a GHCR specific concept?)

I am actively working on this area, and would love more feedback if you give the latest changes a try.

[lmtthws]

I also ran into this, though it was on the pull side when trying to retrieve a ghcr feature through a proxy registry in Artifactory. Artifactory's token endpoint was at a different location than what the CLI constructed. I was able to use the proxy in Artifactory with the oras client. It successfully pulled the artifact from ghcr through artifactory and Artifactory kept a cached copy.

From what I've seen (and is echoed in OCI spec issues 338,240,338), the OCI spec doesn't talk about authorization past saying it may be used, and, if so, here's what error codes to expect.

Docker's registry V2 API is more opinionated and has a specification which speaks more to how authorization should be implemented. The flow they describe (and is supported by Artifactory and ghcr so may be more of a de facto standard) is to contact the registry first and, if a 401 response with a WWW-Authenticate challenge is received, to use the token endpoint in the challenge's realm. That token endpoint may or may not require its own authorization (ghcr and artifactory don't for public registries, ghcr does for private registries(?)).

I'm thinking that might be the approach to take here. There could be some handling built in to go and get a token if we need one while referencing the environment variables if we know the token endpoint is going to require its own authentication, but the default path should probably be to try and get the artifact and, if we get back a 401 challenge, try to get a token from the value in its realm and then re-try the request.

[joshspicer]

Thanks for the links @lmtthws I will investigate this.

[brendandburns]

This PR addresses some of this:

#344

With this PR I can successfully use a feature hosted in Azure Container Registry (at least in my local client), I'm using DEVCONTAINERS_OCI_AUTH in my GH action publish:

https://github.com/dev-wasm/dev-wasm-feature/blob/main/.github/workflows/release.yaml

[joshspicer]

The specification that @lmtthws and others shared has now been implemented in version v0.27.0 of the CLI. It's been tested with GitHub Container Registry and Azure Container Registry.

Keep in mind that only registries implementing the distribution spec outlined here will work for Dev Container Features/Templates

Please let me know if there are other improvements that can be made to the implementation

[aacebedo]

Thanks ! I'll check this when gitlab finishes to implement the spec. I am watching their ticket on this subject.

[albert849]

Great job