MD5 hash #128

New issue

Open

opened 2025-12-28 18:12:39 +00:00 by sami · 1 comment

sami commented

2025-12-28 18:12:39 +00:00

Owner

Originally created by @roman-khimov on GitHub (Jun 25, 2025).

I'm always frustrated when I look at https://github.com/nspcc-dev/neofs-s3-gw/issues/1053.

Describe the solution you'd like

I see no other way to solve it but to add yet another hash field to NeoFS objects (https://github.com/nspcc-dev/neofs-s3-gw/issues/1053#issuecomment-2907792818). Yeah, that's MD5. In 2025.

Describe alternatives you've considered

Unknown.

Originally created by @roman-khimov on GitHub (Jun 25, 2025). ## Is your feature request related to a problem? Please describe. I'm always frustrated when I look at https://github.com/nspcc-dev/neofs-s3-gw/issues/1053. ## Describe the solution you'd like I see no other way to solve it but to add yet another hash field to NeoFS objects (https://github.com/nspcc-dev/neofs-s3-gw/issues/1053#issuecomment-2907792818). Yeah, that's MD5. In 2025. ## Describe alternatives you've considered Unknown.

sami added the

enhancement

labels

2025-12-28 18:12:39 +00:00

sami commented

2025-12-28 18:12:40 +00:00

Author

Owner

@roman-khimov commented on GitHub (Jul 15, 2025):

Consider https://docs.aws.amazon.com/AmazonS3/latest/userguide/checking-object-integrity.html here as well. While technically we can add five more fields to the object structure this would obviously make it a bloody mess of hashes and impact metabase as well. Instead we can consider either:

adding an aux_hashes field with an array of hashes (and deprecate homomorphic_hash? after #339 it's not very useful); container attributes can then regulate which hashes are calculated and stored
adding a __NEOFS__AUX_HASHES user-defined attribute (and using internal S3 slicer) that would allowed to be different for first and last object parent (big) headers, functionally similar to the above one, but application-specific

This would make it impossible to search for something with a particular aux hash, but practically sha256 index from the respective field should be sufficient.

Other ideas are welcome.

@roman-khimov commented on GitHub (Jul 15, 2025): Consider https://docs.aws.amazon.com/AmazonS3/latest/userguide/checking-object-integrity.html here as well. While technically we can add five more fields to the object structure this would obviously make it a bloody mess of hashes and impact metabase as well. Instead we can consider either: * adding an `aux_hashes` field with an array of hashes (and deprecate `homomorphic_hash`? after #339 it's not very useful); container attributes can then regulate which hashes are calculated and stored * adding a `__NEOFS__AUX_HASHES` user-defined attribute (and using internal S3 slicer) that would allowed to be different for first and last object parent (big) headers, functionally similar to the above one, but application-specific This would make it impossible to search for something with a particular aux hash, but practically sha256 index from the respective field should be sufficient. Other ideas are welcome.