Hey all, How can I push this change forward: https://github.com/pulumi/pulumi/pull/14543 Also related, I noticed

CheckpointV3

has a

Config

field, but it seem unused, is there a reason for it? I think it could be great to save the stack config in the same file so that

stack export / import

will also import the configuration.

On my todo list this week. While it looks reasonable at first glance we're a little concerned about the relationships between state and config so gonna give it a think over.

Any chance to look at this as well: https://github.com/pulumi/pulumi/pull/14698 I want to advance it before I advance the former one. I want to change Pulumi to be very explicit about changing secret providers, while we are at it.

I think my comment from the other PR thread stands. Adding a flag like this now is a breaking change and we're generally very reluctant to accept those. Making this an error on empty stdin is also technically a breaking change, but is such a bad use of the system I think we'd be ok with that.

So we are fine with having

rotate

dictate the source of the passphrase? TBH, I'm not even so sure how much passphrase rotation is really used in automated systems to care about breaking it.

Again, I think it would be a break change to change that now 😞 Ideally any change (either new change to passphrase, or a passphrase rotation) would read stdin but given there's probably a lot of code already using the envvar to set this I think we have to keep that working.

To be honest I think that changing secrets in CI is something that doesn’t really happen since a lot of things can go wrong. Which to be fair is the whole point of this work, to read existing secret providers from state and disallow switching secret providers in a non explicit way. I don’t mind dropping this, I just tried to clean this behavior as I advance, I also think that the reason there are not many issues around this, is due to the fact this is mostly unused.

I also think that the reason there are not many issues around this, is due to the fact this is mostly unused.

Maybe, but might just be that most are just using this and it works fine. It's hard to tell given we don't have telemetry, so we have to generally be cautious.

Seems like lots of things can go wrong here, since obviously config + state updates are not atomic.

Well this is why I said config secrets provider should take priority. config can change without a state update, but at least every state update would then consistently be using the provider set by config.

I think that probably the majority of users will not store secrets in config

Nah this is a bad assumption. Lots of users store secrets in config.

bit connected to my question about, should the last used config for some update should be stored

Maybe... I need to look into this more. It is a bit of a confusing system that's grown over the years trying to keep compatibility with what already exists.