Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

do checksum integrity check in installers #439

Open
ashleygwilliams opened this issue Sep 20, 2023 · 1 comment
Open

do checksum integrity check in installers #439

ashleygwilliams opened this issue Sep 20, 2023 · 1 comment
Labels
feature request New feature or request
Milestone

Comments

@ashleygwilliams
Copy link
Member

we make the checksums, let's use them in the installers to add a (thin) layer of security

@ashleygwilliams ashleygwilliams added the feature request New feature or request label Sep 20, 2023
@Gankra Gankra added this to the 0.4.0 milestone Sep 21, 2023
@Gankra
Copy link
Contributor

Gankra commented Sep 21, 2023

Note for implementors, this affects all the "fetching installers", which predate the checksum system and need to be updated to use them:

  • shell
  • powershell
  • npm
  • homebrew

There are two ways to approach this:

  1. bake the checksum into the installer
  2. fetch the checksum file and compare it

The homebrew installer already implements this feature (as expected by homebrew), and it uses the baking strategy. In general baking is faster and more robust, but it comes at the cost of preventing the user for re-uploading binaries or doing post-processing that we don't know about.

The in-tree partial support for signing windows artifacts effectively looks like such a "reupload", which results in us regenerating the checksums for signed files after installers have been built (because the installers are the things we want to sign, and we do all signing in one shot, absent a more complete design for signing that can be interleaved into the build). However this signing support currenly only modifies .msi and .ps1 files -- neither of which is fetched by another installer, so it's not a problem. However it would be reasonable in the future for us to support signing the binaries stored in fetchable archives.

In the future better integration of signing tools (where we interleave signing into the build instead of stamping it on at the end) will resolve all the tension here.

In the immediate term, baking is fine but will block "sign the contents of an archive". If we want to keep "sign the contents of the archive" on the table without fixing the signing design (or just want to let users edit things as long as they regen checksums), then fetching is needed.

I think we should just accept baking (homebrew has to use it anyway) and deal with signing stuff properly down the road (or we disable checksum stuff for signed binaries since they essentially have super-checksums stapled to themselves).

Note that for most installers there isn't really a material difference in security between the solutions, because you fetch the installer from the same server as the archives and everything uses https anyway. The checksums mostly exist to catch things like on-disk data corruption. (Homebrew does get a marginal security benefit here in that taps are a separate github repo, so there are in fact two sources of truth that need to be kept consistent by an attacker.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants