add support for SKOPEO_CREDS environment variable

[koshatul]

What change does this introduce?

Added a check before the command line credentials are applied to use SKOPEO_CREDS environment variable for setting them.

Why make this change?

It is unwieldy to keep setting the creds on the command line when using a private repository on OSX (which doesn't store the creds in the docker config file).

What approach will be taken?

Attempt to set the credentials from the environment first, so if --no-creds or --creds is used on the command line, it will override the environment.

[giuseppe]

the change makes sense. How would it be possible to differentiate src- and dest- as the creds options do now?

[mtrmac]

We must not be sending the credentials to any registry, in particular to both the source and destinations of skopeo copy.

[mtrmac]

My first recommendation would be to use a docker-like config file, if not the global one, then a temporary one set using --authfile, created probably using podman login or perhaps constructed manually.

That immediately handles the source/destination differentiation, as well as scaling to automatically handling many different registries (without the callers of skopeo having to juggle the credentials manually for every single command) and mirrors (which can only use credentials from the file currently, the --{src-,dest-,}creds options are not used).

(I’m not too fond of environment variables in general, it’s too easy to pass configuration through several unaware layers that is invisible or difficult to notice, and thus hard to debug. [Also, it’s awkward that the common convention is to use upper-case environment variable names, which are explicitly reserved by POSIX for system use, i.e. that the common naming convention is exactly the wrong one.]. OTOH that may be an outlier opinion not shared by others.)

[koshatul]

I haven't checked, but if I had set the environment variable, I'd prefer it to send those auth details to both registries, since I'm likely copying between two private registries, if the auth differs, then --src-creds/--src-no-creds or --dst-creds/--dst-no-creds can be used to override.

There is already a standard for this in the .netrc file, but that could be pulling way too ancient a standard into a current utility.

I don't think upper case environment variables are reserved for system use and when a convention is adopted wide enough, resisting just makes it difficult for the average user.
(The Open Group Base Specifications Issue 7, 2018 edition section on Environment Variables says that Shells and Utilities from POSIX.1-2017 use uppercase, and that lowercase is reserved for applications, that doesn't prohibit utilities not in the Shells and Utilities list from using uppercase, just they have to be aware of overlaps)

[koshatul]

The other option is implementing keychain access for OSX so the parsed config.json could still be used and then the keychain interrogated for authorisation of remote registries.

[koshatul]

https://github.com/docker/cli/tree/master/cli/config/credentials is the section of the docker/cli repo that handles credentials, but importing docker/cli just for that section seems bloated at least on building.

[mtrmac]

I haven't checked, but if I had set the environment variable, I'd prefer it to send those auth details to both registries, since I'm likely copying between two private registries

We don’t know that, in general. It’s never for skopeo copy docker://docker.io/library/… private-mirror.example.com/… to send the private credentials to docker.io.

[rhatdan]

@koshatul What do you want to do with this PR? Could we break this into two environment variables, one for source and one for destination?

[mtrmac]

The other option is implementing keychain access for OSX so the parsed config.json could still be used and then the keychain interrogated for authorisation of remote registries.

FWIW some support for credential helpers exist (configuring one registry at a time, not with a global helper, right now), and they use the same protocol as Docker, so this should be possible to set up.

[koshatul]

FWIW some support for credential helpers exist (configuring one registry at a time, not with a global helper, right now), and they use the same protocol as Docker, so this should be possible to set up.

Sorry, I got caught up and didn't get back to this, but it's probably good that I didn't since I would have gone the wrong way in implementing this.

It took me some time to follow the code for that, and I found that it only supported specific credHelpers not the default credStore, I did a PR for the containers/image repository to fix that, which will obsolete this.

So this is replaced by containers/image#737