## 0.17.13 (unreleased) ### Improvements - Fix an issue where creating a first class provider would fail if any of the configuration values for the providers were secrets. (fixes [pulumi/pulumi#2741](https://github.com/pulumi/pulumi/issues/2741)). - Fix an issue where when using `--diff` or looking at details for a proposed updated, the CLI might print text like: `<{%reset%}> --outputs:--<{%reset%}>` instead of just `--outputs:--`. - Fixes local login on Windows. Specifically, windows local paths are properly understood and backslashes `\` are not converted to `__5c__` in paths. - Signature of `Pulumi.all` has been made more accurate. Calling `.all` on `Output`s that may be `undefined` will properly encode and pass along that `undefined` information. - Fix an issue where some operations would fail with `error: could not deserialize deployment: unknown secrets provider type`. ## 0.17.12 (Released May 15, 2019) ### Improvements - Pulumi now tells you much earlier when the `--secrets-provider` argument to `up` `init` or `new` has the wrong value. In addition, supported values are now listed in the help text. (fixes [pulumi/pulumi#2727](https://github.com/pulumi/pulumi/issues/2727)). - Pulumi no longer prompts for your passphrase twice during operations when you are using the passphrase based secrets provider. (fixes [pulumi/pulumi#2729](https://github.com/pulumi/pulumi/issues/2729)). - Fix an issue where complex inputs to a resource which contained secret values would not be stored correctly. - Fix a panic during property diffing when comparing two secret arrays. ## 0.17.11 (Released May 13, 2019) ### Major Changes #### Secrets and Pluggable Encryption - The Pulumi engine and Python and NodeJS SDKs now have support for tracking values as "secret" to ensure they are encrypted when being persisted in a state file. `[pulumi/pulumi#397](https://github.com/pulumi/pulumi/issues/397)` Any existing value may be turned into a secret by calling `pulumi.secret()` (NodeJS) or `Output.secret(`) (Python). In both cases, the returned value is an output which may be passed around like any other. If this value flows into a resource, the plaintext will not be stored in the state file, but instead It will be encrypted, just like values added to config with `pulumi config set --secret`. You can verify that values are being stored as you expect by running `pulumi stack export`, When values are encrypted in the state file, they appear as an object with a special signiture key and a ciphertext property. When ouputs of a stack are secrets, `pulumi stack output` will show `[secret]` as the value, by default. You can pass `--show-secrets` to `pulumi stack output` in order to see the actual raw value. - When storing state with the Pulumi Service, you may now elect to use the passphrase based encryption for both secret configuration values and values that are encrypted in a state file. To use this new feature, pass `--secrets-provider passphrase` to `pulumi new` or `pulumi stack init` when you initally create the stack. When you create the stack, you will be prompted for a passphrase (or if `PULUMI_CONFIG_PASSPHRASE` is set, it will be used). This passphrase is used to generate a unique key for your stack, and config values and encrypted state values are encrypted using AES-256-GCM. The key is derived from your passphrase, and while information to re-create it when provided with your passphrase is stored in both the `Pulumi..yaml` file and the state file for your stack, this information can not be used to recover the key. When using this mode, the Pulumi Service is unable to decrypt either your secret configuration values or and secret values in your state file. We will be adding gestures to move existing stacks managed by the service to use passphrase based encryption soon as well as gestures to change the passphrase for an existing stack. ** Note ** Stacks with encrypted secrets in their state files can only be managed by 0.17.11 or later of the CLI. Attempting to use a previous version of the CLI with these stacks will result in an error. Fixes #397 ### Improvements - Add support for Azure Pipelines in CI environment detection. - Minor fix to how Azure repository information is extracted to allow proper grouping of Azure repositories when various remote URLs are used to pull the repository. ## 0.17.10 (Released May 2, 2019) ### Improvements - Fixes issue introduced in 0.17.9 where local-login broke on Windows due to the new support for `s3://`, `azblob://` and `gs://` save locations. - Minor contributing document improvement. - Warnings from `npm` about missing description, repository, and license fields in package.json are now suppressed when `npm install` is run from `pulumi new` (via `npm install --loglevel=error`). - Depend on newer version of gRPC package in the NodeJS SDK. This version has prebuilt binaries for Node 12, which should make installing `@pulumi/pulumi` more reliable when running on Node 12. ## 0.17.9 (Released April 30, 2019) ### Improvements - `pulumi login` now supports `s3://`, `azblob://` and `gs://` paths (on top of `file://`) for storing stack information. These are passed the location of a desired bucket for each respective cloud provider (i.e. `pulumi login s3://mybucket`). Pulumi artifacts (like the `xxx.checkpoint.json` file) will then be stored in that bucket. Credentials for accessing the bucket operate in the normal manner for each cloud provider. i.e. for AWS this can come from the environment, or your `.aws/credentials` file, etc. - The pulumi version update check can be skipped by setting the environment variable `PULUMI_SKIP_UPDATE_CHECK` to `1` or `true`. - Fix an issue where the stack would not be selected when an existing stack is specified when running `pulumi new