This message was deleted.

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" },
    });

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.

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.

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.

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?

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.

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.

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.

👍 good to hear, i think that is the correct response.. thank you for taking action