https://pulumi.com logo
Title
d

delightful-monkey-90700

02/07/2023, 12:28 AM
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)
o

orange-policeman-59119

02/07/2023, 3:15 AM
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.)
That said, the plugin nature of Pulumi means you should expect a full build (producing a tarball) of the CLI will require assets from other repositories. Right now that means pulumi-watch[.exe], as well as language plugins for Java, .NET, and YAML. Eventually other plugins will be split out as well.
d

delightful-monkey-90700

02/07/2023, 5:00 PM
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
o

orange-policeman-59119

02/07/2023, 5:43 PM
@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.
So I hope it makes sense why we've intertwined the two, it reduces the likelihood that someone else packaging up Pulumi creates a distribution that we can't support.
d

delightful-monkey-90700

02/07/2023, 5:46 PM
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
o

orange-policeman-59119

02/07/2023, 5:46 PM
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.
d

delightful-monkey-90700

02/07/2023, 5:47 PM
I'm packaging it for internal use within our organization.
o

orange-policeman-59119

02/07/2023, 5:48 PM
Do you find our public releases (which are signed with sigstore) insufficient for your use cases?
Add documentation on how to create a correct, complete, and proper release;
I don't know if we're at a point where our processes are stable enough or self-contained enough to document that. Like I said with respect to cross-compiling for macOS, our build process required multiple workers on different OSes until recently. We can't rule out that a change in Golang forces us to do the same in the future.
1. Add a test step which validates at the very least the existence of all the requisite components
I think @worried-rain-74420, on the team that manages the CLI releases, would very much agree. The bug reports we've seen because of improper packaging of the CLI have frustrated users.
d

delightful-monkey-90700

02/07/2023, 5:54 PM
I don't have confidence in the public release being from the released sources due to issues building it locally.
o

orange-policeman-59119

02/07/2023, 7:48 PM
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.
If we get on the phone and chat though, we could chat more about what tweaks might meet your needs, such as acquiring those binary dependencies in a make target that is separate from one that runs
goreleaser
.