Pants: Pants binary dependencies should include hashes that can be checked against public trusted hashes

Created on 8 Aug 2017  路  1Comment  路  Source: pantsbuild/pants

Since pants serves up static binaries generated by others, eg: go, node and other distributions, it is imperative we can compare a hash of the binaries with the most trusted public hashes of the originals.

This PR by a pants contributor - not committer - helps highlight the concern. We should serve a go distribution as trustworthy as those served by golang and right now we allow arbitrary modification and act as a man in the middle: https://github.com/pantsbuild/binaries/pull/27

bug enhancement

Most helpful comment

@illicitonion, @kwlzn and I have been discussing what the next steps for binutils might be.

The key for an artifact is currently platform/architecture/name/version/artifact, where the first two components are determined based on the host machine, and the last three are configured by a user.

It's a desirable property of this system that in order to change the version from x.y.z to x.y.y, it does not take an amount of configuration that is proportional to the total number of platforms/architectures: that portion is already provided by the storage (in this case, the layout defined in https://github.com/pantsbuild/binaries).

The proposal is to move from storing the permutations of the first two components of the key (platform/architecture) in explicit directory listings in the store, into storing a Directory/Snapshot (as defined in #4585) that lists the permutations of platform/architecture.

The UX of changing the version of a tool would then involve changing the version, and specifying the hash of the Directory that lists the platform specific binaries: ie:

[protoc]
version: 1.2.3
manifest: 5de35803fa2...

_* There are other requirements for something like this: namely, a way to sync "all" of the relevant binaries from pants' s3 store on-premise to a user's local store_

>All comments

@illicitonion, @kwlzn and I have been discussing what the next steps for binutils might be.

The key for an artifact is currently platform/architecture/name/version/artifact, where the first two components are determined based on the host machine, and the last three are configured by a user.

It's a desirable property of this system that in order to change the version from x.y.z to x.y.y, it does not take an amount of configuration that is proportional to the total number of platforms/architectures: that portion is already provided by the storage (in this case, the layout defined in https://github.com/pantsbuild/binaries).

The proposal is to move from storing the permutations of the first two components of the key (platform/architecture) in explicit directory listings in the store, into storing a Directory/Snapshot (as defined in #4585) that lists the permutations of platform/architecture.

The UX of changing the version of a tool would then involve changing the version, and specifying the hash of the Directory that lists the platform specific binaries: ie:

[protoc]
version: 1.2.3
manifest: 5de35803fa2...

_* There are other requirements for something like this: namely, a way to sync "all" of the relevant binaries from pants' s3 store on-premise to a user's local store_

Was this page helpful?
0 / 5 - 0 ratings