mirror of
https://github.com/opentffoundation/opentf.git
synced 2026-03-23 13:00:40 -04:00
7a65677851
Our handling of Docker-style configuration files as an authentication source is intentionally a bit of a compromise because various other software reads and writes these files despite there being no single standard for the format, and unfortunately different software makes different tradeoffs when the configuration is ambiguous. One oddity that we didn't notice originally is that the "login" command of some programs will respect the "credsStore" property for storing new credentials using a helper program instead of storing them in cleartext in the config file BUT will still create an empty entry in the "auths" property for whatever domain the operator logged into. Our logic wasn't built to tolerate an "auths" entry without an "auth" property inside it and so we would then fail to select credentials correctly for the affected domain. This commit makes our handling a little more resilient against oddly-generated configuration files by silently ignoring all three of the following oddities: - An "auths" entry that has no "auth" property, as described above. - An "auths" entry that is JSON null, which would previously cause OpenTofu to crash with a null pointer dereference. - An "auths" entry with "auth" set to an empty string, since generating that instead of omitting the property entirely is a relatively common mistake when using Go's encoding/json library and forgetting to add the special "omitempty" tag to the corresponding struct field. (An empty string is never a valid value for this property because it's supposed to be the base64 encoding of a string like "username:password", and so it should always at least contain a base64-encoded colon.) Since there is no plausible valid meaning of any of these odd constructions we prefer to just silently ignore them without any errors and without generating any distracting log noise, which seems to match how other software like Docker CLI and ORAS CLI handles them. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>