Docker login gains a password input for automation

An automated login should not need to put a password in the argument list used to launch the client. Docker 17.07 adds a standard-input option for registry passwords, giving automation a direct input channel for the value. The change is small in syntax but specific in effect. The password no longer has to be supplied as the value of a command-line option.

The 17.07.0-ce release notes date this release to 29 August. Alongside --password-stdin, they add a warning recommending it when someone uses the existing password option. The release also adds proxy configuration in the client configuration file. Both changes concern inputs that depend on the environment where the client runs, rather than the application's source tree.

I prefer keeping that material separate from the image description. A Dockerfile is valuable because it makes the environment needed to build or run a program explicit. Registry credentials and a particular network's proxy address belong to a different relationship between the client, its services and the machine running the command.

Standard input has a defined contract

Tycho Andersen's password-input patch describes three deliberate behaviors. Standard-input password mode conflicts with an explicit password, requires a username and strips a trailing newline. The implementation reads the input before continuing with the ordinary login path. A file-fed invocation can therefore express the operation without placing the password bytes directly in its arguments:

docker login --username build-user --password-stdin < registry-password.txt

This example assumes the file already contains the intended credential. The file name is visible in the command, while its contents enter through standard input. The new option changes how the client receives the value. It does not make the file a managed secret store or determine who may read it.

The username requirement follows from the use of standard input. The client cannot use the same incoming stream both as an unspecified interactive username response and as the password payload. Requiring --username makes the intended interpretation unambiguous before it consumes the bytes.

The implementation removes one trailing newline and then one trailing carriage return. That accommodates input ending in the usual line termination without treating those characters as part of the password. It does not strip arbitrary leading or trailing whitespace. Automation should therefore supply the credential as the payload expected by this interface, rather than assuming a general whitespace-cleaning operation.

Argument handling and credential storage are different questions

The patch changes the warning on the existing --password path to recommend --password-stdin. When both forms are supplied, the command returns an error. That is useful because silently selecting one source would make a script's behavior depend on an implicit precedence rule for sensitive input.

The scope of the change remains the login input path. It reads bytes and assigns the resulting value to the password used by the rest of login. Nothing in this patch establishes a new encrypted storage format or a different lifetime for registry credentials after login. Those questions belong to the mechanisms that handle the resulting authentication configuration.

This distinction matters in a build system. Moving the value out of command arguments addresses that particular exposure. The source process still has to obtain the value, and the Docker client still receives it. A script that prints its input or copies the credential into an image would create separate problems unaffected by this option.

The value of a small interface improvement is that it lets automation follow the intended path without emulating an interactive terminal. The implementation gives a reader enough detail to understand which inputs are required and how errors behave. That is more useful than treating the new flag as a general promise about every part of credential handling.

Proxy defaults move into client configuration

Dave Tucker's proxy configuration patch adds a proxies map to config.json. Each entry can contain HTTP, HTTPS, FTP and no-proxy settings. The client selects a configuration using the daemon host, falling back to the default entry if no host-specific entry exists. A minimal configuration fragment shows the shape of that data:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.example.com:3128",
      "httpsProxy": "http://proxy.example.com:3128",
      "noProxy": "localhost,127.0.0.1"
    }
  }
}

The patch applies these settings as build arguments during image builds and as environment settings for docker run. That is a client behavior. It should not be confused with configuring the daemon's own outbound network access, since the code shown changes inputs submitted for builds and containers.

The selection rule is also more specific than merging every setting into one global environment. A matching daemon-host entry takes the place of the default entry. This permits one client to use different proxy assumptions when it targets different daemons. The relationship follows the daemon endpoint selected by the client.

Explicit values keep precedence

The proxy conversion function begins with the explicit options supplied for the operation. It adds configured proxy values only for entries that are not already present. The tests demonstrate that an explicitly empty NO_PROXY stays empty, which is different from treating an empty value as an absent option.

Both uppercase and lowercase forms are populated when missing. The tests also show that overriding an uppercase variable does not necessarily override its lowercase counterpart. A configured default can remain in the other spelling. That detail matters for programs that choose one spelling when they inspect the environment.

This makes proxy defaults a convenience with a concrete precedence model. The client reduces repetition across commands, but the final environment still depends on explicit options and the spelling consumed by the program. Reading the tests clarifies that behavior more precisely than the release note's short statement that proxy configuration is supported.

I find these changes useful because they put environment-specific inputs into interfaces designed to receive them. Standard input supplies the registry password, and client configuration supplies repeatable proxy defaults. Neither has to become part of the application's image recipe. Automation can describe those dependencies at the point where the client actually needs them, with the precedence and input rules visible in the implementation.