index file hash algorithm

jku / pip

pip fork to experiment with PEP-458 implementation https://www.python.org/dev/peps/pep-0458/: See branch tuf-v2 (and tuf-mvp and tuf-mvp-vendored for earlier work)

https://pip.pypa.io/

MIT License

1 stars 0 forks source link

index file hash algorithm #23

Closed jku closed 4 years ago

jku commented 4 years ago

My impression is that the client only supports sha256 and this is not configurable:

updater provides no way for user to select hash algorithm per target download
settings.py:DEFAULT_HASH_ALGORITHM is not used as the default value in updater.py

Warehouse folks seem to expect they can use blake2b for index file hashes too...

jku commented 4 years ago

Ah no: the Updater target file download does use the first hash from targetinfo.hashes list -- this should be blake2b in our case. The hard-coded function _get_target_hash() seems to actually calculate the hash of the target path in the case of hashed bin delegation.

So this issue is probably invalid

jku commented 4 years ago

So testing this in my mock warehouse: this seems to work... however, the hash seems suspiciously long (128 bytes) whereas the blake2b hashes I've seen Warehouse use are 64 bytes

Former is BLAKE2B-512 (hashlib digestsize=64), latter is BLAKE2B-256 (hashlib digestsize=32), it seems? This is very likely to lead to issues: the download will work fine but the verification will fail because securesystemslib will return BLAKE2B-512 for the file content and then tuf will compare it to BLAKE2B-256 given by warehouse.

jku commented 4 years ago

There is now a PR in securesystemslib to add a new blake2b-256 algorithm. Warehouse should use 'blake2b-256' as the hash identifier in target metadata once it is released.

jku commented 4 years ago

closing as this should not be an issue in client