Commit Graph

10 Commits

Author SHA1 Message Date
Kristin Laemmert 47e657c611
internal/getproviders: decode and return any registry warnings (#25337)
* internal/getproviders: decode and return any registry warnings

The public registry may include a list of warnings in the "versions"
response for any given provider. This PR adds support for warnings from
the registry and an installer event to return those warnings to the
user.
2020-06-25 10:49:48 -04:00
Alisdair McDiarmid e27a36cafd internal/getproviders: Retry failed HTTP requests
This is a port of the retry/timeout logic added in #24260 and #24259,
using the same environment variables to configure the retry and timeout
settings.
2020-05-13 09:48:41 -04:00
Kristin Laemmert 60321b41e8
getproviders: move protocol compatibility functions into registry client (#24846)
* internal/registry source: return error if requested provider version protocols are not supported

* getproviders: move responsibility for protocol compatibility checks into the registry client

The original implementation had the providercache checking the provider
metadata for protocol compatibility, but this is only relevant for the
registry source so it made more sense to move the logic into
getproviders.

This also addresses an issue where we were pulling the metadata for
every provider version until we found one that was supported. I've
extended the registry client to unmarshal the protocols in
`ProviderVersions` so we can filter through that list, instead of
pulling each version's metadata.
2020-05-11 13:49:12 -04:00
Alisdair McDiarmid a5b3d497cc internal: Verify provider signatures on install
Providers installed from the registry are accompanied by a list of
checksums (the "SHA256SUMS" file), which is cryptographically signed to
allow package authentication. The process of verifying this has multiple
steps:

- First we must verify that the SHA256 hash of the package archive
  matches the expected hash. This could be done for local installations
  too, in the future.
- Next we ensure that the expected hash returned as part of the registry
  API response matches an entry in the checksum list.
- Finally we verify the cryptographic signature of the checksum list,
  using the public keys provided by the registry.

Each of these steps is implemented as a separate PackageAuthentication
type. The local archive installation mechanism uses only the archive
checksum authenticator, and the HTTP installation uses all three in the
order given.

The package authentication system now also returns a result value, which
is used by command/init to display the result of the authentication
process.

There are three tiers of signature, each of which is presented
differently to the user:

- Signatures from the embedded HashiCorp public key indicate that the
  provider is officially supported by HashiCorp;
- If the signing key is not from HashiCorp, it may have an associated
  trust signature, which indicates that the provider is from one of
  HashiCorp's trusted partners;
- Otherwise, if the signature is valid, this is a community provider.
2020-04-17 13:57:19 -04:00
Martin Atkins 0ad4c1be2f internal/getproviders: Tidy up some confusion about package hashes
Earlier on in the stubbing of this package we realized that it wasn't
going to be possible to populate the authentication-related bits for all
packages because the relevant metadata just isn't available for packages
that are already local.

However, we just moved ahead with that awkward design at the time because
we needed to get other work done, and so we've been mostly producing
PackageMeta values with all-zeros hashes and just ignoring them entirely
as a temporary workaround.

This is a first step towards what is hopefully a more intuitive model:
authentication is an optional thing in a PackageMeta that is currently
populated only for packages coming from a registry.

So far this still just models checking a SHA256 hash, which is not a
sufficient set of checks for a real release but hopefully the "real"
implementation is a natural iteration of this starting point, and if not
then at least this interim step is a bit more honest about the fact that
Authentication will not be populated on every PackageMeta.
2020-04-06 16:31:23 -07:00
Martin Atkins 43c1ec69e2 build: Use Go 1.14
This implies some notable changes that will have a visible impact to
end-users of official Terraform releases:

- Terraform is no longer compatible with MacOS 10.10 Yosemite, and
  requires at least 10.11 El Capitan. (Relatedly, Go 1.14 is planned to be
  the last release to support El Capitan, so while that remains supported
  for now, it's notable that Terraform 0.13 is likely to be the last major
  release of Terraform supporting it, with 0.14 likely to further require
  MacOS 10.12 Sierra.)

- Terraform is no longer compatible with FreeBSD 10.x, which has reached
  end-of-life. Terraform now requires FreeBSD 11.2 or later.

- Terraform now supports TLS 1.3 when it makes connections to remote
  services such as backends and module registries. Although TLS 1.3 is
  backward-compatible in principle, some legacy systems reportedly work
  incorrectly when attempting to negotiate it. (This change does not
  affect outgoing requests made by provider plugins, though they will see
  a similar change in behavior once built with Go 1.13 or later.)

- Ed25519 certificates are now supported for TLS 1.2 and 1.3 connections.

- On UNIX systems where "use-vc" is set in resolv.conf, TCP will now be
  used for DNS resolution. This is unlikely to cause issues in practice
  because a system set up in this way can presumably already reach its
  nameservers over TCP (or else other applications would misbehave), but
  could potentially lead to lookup failures in unusual situations where a
  system only runs Terraform, has historically had "use-vc" in its
  configuration, but yet is blocked from reaching its configured
  nameservers over TCP.

- Some parts of Terraform now support Unicode 12.0 when working with
  strings. However, notably the Terraform Language itself continues to
  use the text segmentation tables from Unicode 9.0, which means it lacks
  up-to-date support for recognizing modern emoji combining forms as
  single characters. (We may wish to upgrade the text segmentation tables
  to Unicode 12.0 tables in a later commit, to restore consistency.)

This also includes some changes to the contents of "vendor", and
particularly to the format of vendor/modules.txt, per the changes to
vendoring in the Go 1.14 toolchain. This new syntax is activated by the
specification of "go 1.14" in the go.mod file.

Finally, the exact format of error messages from the net/http library has
changed since Go 1.12, and so a couple of our tests needed updates to
their expected error messages to match that.
2020-03-04 13:26:50 -08:00
Martin Atkins 3078d21c5f internal/getproviders: Include Provider and Version in PackageMeta
Although we tend to return these in contexts where at least one of these
values is implied, being explicit means that PackageMeta values are
self-contained and less reliant on such external context.
2020-02-25 10:30:03 -05:00
Martin Atkins a77bc59c44 internal/getproviders: Package URL should always be absolute
Registries backed by static files are likely to use relative paths to
their archives for simplicity's sake, but we'll normalize them to be
absolute before returning because the caller wouldn't otherwise know what
to resolve the URLs relative to.
2020-01-10 09:41:27 -08:00
Martin Atkins c8f7223adb internal/getproviders: Source interface for generalization
We intend to support installation both directly from origin registries and
from mirrors in the local filesystem or over the network. This Source
interface will serve as our abstraction over those three options, allowing
calling code to treat them all the same.
2020-01-10 09:41:27 -08:00
Martin Atkins c76260e957 internal/getproviders: Query a provider registry
Our existing provider installer was originally built to work with
releases.hashicorp.com and later retrofitted to talk to the official
Terraform Registry. It also assumes a flat namespace of providers.

We're starting a new one here, copying and adapting code from the old one
as necessary, so that we can build out this new API while retaining all
of the existing functionality and then cut over to this new implementation
in a later step.

Here we're creating a foundational component for the new installer, which
is a mechanism to query for the available versions and download locations
of a particular provider.

Subsequent commits in this package will introduce other Source
implementations for installing from network and filesystem mirrors.
2020-01-10 09:41:27 -08:00