Docker 18.09.7 corrects the repository boundary in GCR authentication

Two repositories on the same registry can require different authentication handling. Docker 18.09.7 includes a correction to a Google Container Registry workaround that had cached resolver state by domain when it needed a repository name. The change is a useful example of an authentication failure caused by a cache key that discards meaningful identity information.

The June 27 release notes include both the original GCR workaround and the correction to its token cache. They also include a builder fix for comment-only Dockerfiles. These changes concern different inputs, but both become clearer when the implementation is read alongside the one-line changelog.

I value a repeatable build file because it makes the environment construction explicit. That benefit depends on the builder interpreting repository identity and invalid input consistently. Neither issue changes the Dockerfile's intended application, yet either can stop its construction before the application build runs.

An authentication workaround creates reusable state

Moby pull request 38246 explains the original workaround. GCR blob endpoints did not return the expected 401 response. The builder detected when its resolver had made no manifest request and issued a dummy request to enable authorization. That inserted a preparatory request into an otherwise failing authentication sequence.

This is an interoperability adjustment to the request flow. The builder needs authorization state before fetching the relevant content, and the blob endpoint does not supply the response the normal flow expects. A manifest request supplies another opportunity to establish that state. The pull-request description presents it as a workaround pending a registry correction.

Once a resolver containing that state is cached, the choice of cache identity becomes part of the authentication behavior. A domain describes the registry service, but a repository describes the particular named content within it. Reusing the same resolver across those names can therefore combine requests that should have separate repository-specific state.

Pull request 39183, merged May 7, identifies exactly that problem. Its description says the workaround used a domain as the cache key when it should have used a repository name. The correction is included in this maintenance release rather than introducing a different registry authentication protocol.

The session stays in the key

The patch changes both insertion and lookup. Where the key previously combined the domain with the current session, it now combines the parsed repository name with that session. Updating both operations preserves agreement between where state is stored and where it is sought.

The helper previously returned the domain from a normalized image reference. It now returns the reference's name. If parsing fails, the helper retains the supplied reference string. The meaningful change for valid image references is preserving repository identity instead of reducing the name to a shared host.

The session component remains present. That detail matters because the fix narrows the repository part of an existing key rather than replacing the entire isolation arrangement. Describing the correction simply as adding authentication caching would miss the existing state. Describing it as removing the cache would be equally inaccurate.

There is a general design implication here, although the mechanism is specific. A cache that retains authentication-related state needs a key at least as precise as the state it stores. Dropping part of a resource name is safe only when that part does not affect reuse. In this workaround, the repository component affects reuse and therefore belongs in the key.

A comment is not a build instruction

The comment-only Dockerfile fix handles a different boundary. Pull request 38487 reports a panic when building a file containing only a comment. The fix detects a parse result with no instruction constructs and returns an input error instead.

The diff adds tests for an empty file, a file containing empty lines, and a comment-only file. Those latter cases expect an error identifying a file with no instructions. The parser can consume text without producing a meaningful build, so a successful read alone cannot establish a valid instruction sequence.

That distinction is useful for generated Dockerfiles as well as handwritten ones. A template can leave behind whitespace or comments after all instruction-producing branches are omitted. The correct response is an error about the submitted build description. The builder should not proceed as if the root syntax node described an executable build operation.

My interest in small Dockerfiles includes being able to explain their behavior from their contents. A comment-only file has no such build behavior to execute. Returning the explicit error preserves that distinction for the caller and confines the failure to the invalid request.

In this release, repository-aware resolver reuse restores the intended scope of the GCR workaround. The parser correction independently rejects text that contains no build instructions. Both fixes preserve information needed by the next stage, the repository name in one case and the absence of instructions in the other.