https://pulumi.com logo
Title
b

brave-angle-33257

05/06/2022, 8:19 PM
suddenly getting an error in my automation API in a docker container stating:
passphrase must be set with PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE
but when I print out the ENV vars above (running in docker) it's listed.
adding this to the local workspace vars, haven't had to do this before, and these vars are in scope of the container running it:
// create (or select if one already exists) a stack that uses our inline program
    const stack = await LocalWorkspace.createOrSelectStack(args, {
        projectSettings: projectArgs,
        envVars: { PULUMI_CONFIG_PASSPHRASE: "XXX", PULUMI_HOME: "/tmp/pulumi_home" },
    });
bash-4.2# pulumi version
v3.32.1
bash-4.2# pulumi plugin ls
NAME    KIND      VERSION  SIZE    INSTALLED  LAST USED
aws     resource  4.24.1   286 MB  n/a        5 minutes ago
docker  resource  3.2.0    40 MB   n/a        5 minutes ago
gotta be a regression in 3.32.1
so you can't use a blank password anymore? there is danger of deleting stack?? wow that's not good
I am using an empty passphrase for virtually everything, I don't store anything secret in the state files, and the hassle of using a passphrase in 1000+ stacks is challenging
Should I be worried that stacks are in danger of being deleted on older stacks? that could catastrophic
what's the approach to handle this moving forward for existing stacks?
e

echoing-dinner-19531

05/06/2022, 9:13 PM
I don't think it can actually delete stacks. What it can do is create malformed empty stacks, that's always been possible to do by ctrl-c'ing out when it prompted for a password.
And an empty passphrase will still work, but you need to set it via PULUMI_CONFIG_PASSPHRASE_FILE pointing to an empty file. PULUMI_CONFIG_PASSPHRASE="" is treated the same as PULUMI_CONFIG_PASSPHRASE being unset. This is fairly normal for envvar behaviour and we misjudged how much people we're actually using empty passphrases, so we didn't think it would have the impact it's had. We currently having internal discussions about what we should do.
b

brave-angle-33257

05/07/2022, 3:46 AM
Thanks.. I think you need to put it back where it accepts
PULUMI_CONFIG_PASSPHRASE=""
as a valid command.. maybe it's not "usual" but it's something that is pretty heavily ingrained in Pulumi world afaik.. I know it is for my org. The encryption of the stacks/passphrase should be optional imo, it's not something that is used very often in practice unless you are using secrets.
I'd have to update multiple CI/CD pipelines and containers to use
PULUMI_CONFIG_PASSPHRASE_FILE
pointing to an empty file that I imagine I would need to
touch
in order to achieve parity to where i was just a few days ago
e

echoing-dinner-19531

05/07/2022, 8:00 AM
The encryption of the stacks/passphrase should be optional imo, it's not something that is used very often in practice unless you are using secrets. (edited)
To be accurate setting it to "" isn't opting out of encryption, its just encrypting with an empty key. But we've seen enough cases of people doing this that reverting to allowing the envvar to be the empty string is an option we're looking at.
b

brave-angle-33257

05/07/2022, 3:39 PM
Sure, that makes sense.. but for intents and purposes, it indicates a desire of the user to not dip a toe into the "password protected" state file game. If that means internally encrypting it with an empty string, that's fine. But yes, I would applaud a move back to allow it with original behavior. To be clear, if everyone is using empty strings, and I 'get ahold' of someone else's state file, are there other security downsides besides being able to read their stack config secrets?
e

echoing-dinner-19531

05/07/2022, 3:43 PM
are there other security downsides besides being able to read their stack config secrets?
That's a pretty big one alone. One of our main concerns is that it's currently easy to set an empty password, but we also tell people it's ok to commit their config to vcs because secrets are encrypted and it's a pretty easy failure pit to fall into if someone does both of these things.
Having said that, we'll probably revert this for now and then rethink exactly where we want to take this given we already have users using this empty password behaviour.
b

brave-angle-33257

05/07/2022, 3:46 PM
yes, but for clarification purposes, sounds like that is the main issue. generally for my org we don't use stack secrets much at all, and generally use aws param store so just wanted to confirm.
e

echoing-dinner-19531

05/11/2022, 3:57 PM
N.B We've reverted this behaviour change to allow PULUMI_CONFIG_PASSPHRASE to be set to "" again. It will be in the next release.
b

brave-angle-33257

05/11/2022, 4:02 PM
👍 good to hear, i think that is the correct response.. thank you for taking action