Is anyone using Pulumi within a PCI-DSS environment given that it downloads and runs code from the Internet without any integrity checking ? Right now, I manually verify that the checksums of the downloaded plugins match, but that requires downloading a file which contains the checksums -- but there's no way to verify the integrity of that file (i.e., it's not signed or anything).

We use sigstore to sign the archives we publish on github.com/pulumi/pulumi/releases

Since that's not done, there's no automated integrity checking for the code that is downloaded -- that means manual integrity checking is the only option (with respect to PCI-DSS), but there's no way to anchor the trust in the checksums files to anything so it's a pointless check that doesn't accomplish the goal.

The signatures on pulumi/pulumi are signed to the sigstore root authority and can be verified via

cosign

. To your point, we have a ways to go to enable runtime checks.

It's not very meaningful with respect to my question to state that Pulumi the binary has a signature, the question is about the executables that are download and run without any integrity checking.

curl

is also signed, but if I download random code and run it, that code has not been verified.

I'm not sure, there's often room in compliance regimes to replace automated controls with human ones, attestations, or relying e.g. on the security of the third parties. I don't believe any compliance regimes require all binaries to be signed, though the President's EO on supply chain security and recent announcements are on my mind.

PCI-DSS requires that code being executed has integrity verified -- signatures are a way to accomplish this by trusting a private key is protected, which can be done one time -- versus unsigned checksums which must be manually verified (I guess by sending you an email?) every time

Integrity verification can mean many things, e.g.: that the download was what our system transmitted. That can be asserted by using TLS, which we utilize.

That's certainly not verifying the integrity of the resource, it's verifying the integrity of the channel and hoping for the best for the resource. FWIW, when I did this with Go previously I just use a simple PKCS#1 v1.5 signature with an HSM holding the private key.

As an open source project with many teams within and without Pulumi producing providers, we have - I hope you consider this reasonable - not opted to enforce code signing on every OSS provider binary.

( https://github.com/perlin-network/wavelet/blob/master/cmd/wavelet/update.go )

We do plan on verifying plugins with checksums. Assuming you trust the package manager that delivers the pulumi SDKs (npm/nuget/etc) that code will contain the checksums it expects for the plugin binaries it will run against. Given that if your in this sort of environment you should have already solved the "how do we trust and verify the package manager" problem, we can just piggy back off that.

I think Terraform is verifying every binary it downloads. If you want to publish anything to their registry, it must be signed and the signature is verified during

terraform init

(https://developer.hashicorp.com/terraform/registry/providers/publishing). Maybe Pulumi can do something similar?

Yeah, I created that issue almost a year ago 😕

There has been some progress on that in the background, it's just one of those things where its not really useful to users until all the work on it is done.