I'm building

pulumi

from source (v3.54.0) and it attempts to download something as part of the build step without verifying that what it fetched was what it intended to fetch:

+ curl -OL --fail <https://github.com/pulumi/watchutil-rs/releases/download/v0.1.4/pulumi-watch-v0.1.4-x86_64-unknown-linux-gnu.tar.gz>
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (7) Couldn't connect to server

(it fails since it's part of the build step, and building is done offline)

While we could do better here and we have loose plans to plumb sigstore/cosign through every step (@many-telephone-49025 and I have worked on this), we considered the threat here fairly low. It's hard coded to download a release from GitHub, so the MITM risk is slim. (GitHub being one of the most monitored certificates in the world, and all.)

I'm fine with assets from other repositories -- I downloaded all of the dependencies, which came from many repositories, as part of the download phase. Additionally, they had checksums to verify that I was getting the correct and expected items at time of package creation. The issues here are: 1. That it fails to download everything and some things are downloaded during the build phase, which will not work for people who perform offline builds, which is one part of reproducible and deterministic builds. 2. There's no way to verify that what I got was intended at time of release, since release files can be modified -- this isn't limited to MITM; For the release file itself I download it and verify the hash. 3. There's no documentation related to any of this process You don't need digital signatures to solve this (though that's one way to go and you should probably have GPG or S/MIME signed hashes on release anyway to tie the releases to a private key, ideally one on an HSM), since you're already in a trusted process -- you just need to verify the hash after downloading it, and download it before building. For reference, I do something similar when downloading remote resources and here is the script I use to validate the hash (though this also caches it by hash): https://kitcreator.rkeene.org/fossil/artifact/d546c4b48dfce807?ln

@delightful-monkey-90700 That's fair feedback! I think that from our POV we have been stymied in the past when other tools / package managers come along and try to package up Pulumi and ran a custom build step (skipping other steps). This has resulted in bugs where users report no programs succeed because their package manager's distribution contains

pulumi[.exe]

but not any language plugins.

I understand, having helped manage large open source projects for a long time, some things that could help (and have helped in other cases): 1. Add documentation on how to create a correct, complete, and proper release; 2. Add a test step which validates at the very least the existence of all the requisite components

Can you give any more info on your use case for repackaging Pulumi? I can give you pointers or we can create issues - they may not be our highest priority at the moment as CI is fairly fickle and we rely on a mix of GitHub Actions and

make

targets to package the CLI in an efficient manner. For example, until very very recently to work around bugs in cross-compiling to macOS, we built the macOS targets on macOS and combined them in GitHub Actions.

I'm packaging it for internal use within our organization.

Do you find our public releases (which are signed with sigstore) insufficient for your use cases?

I don't have confidence in the public release being from the released sources due to issues building it locally.

I see, what can I do as someone who largely built our current build process to assuage your concerns? I'm happy to spend a few minutes chatting (video chat, call) about the process to describe the rigor we put into it. Regarding documenting or improving the makefile process, I think the pulumi/pulumi repo is happy to accept issues to improve docs, but there is no world I can see in which the makefile describes the build process we use to produce releases, if that makes sense.