Comment 1 for bug 1691807

@Ruslan Hello. I hope you don't mind, but I was thinking about this wishlist bug this weekend and have come up with some questions and a patch (#473149) to demonstrate what I was thinking. But I see that you are the assignee on this bug. It would be great to get your feedback on what I have proposed. Have you started work on this issue? If so, we can work together on the solution if you would like. You can reach me in #openstack-swift as jrichli

@Alistair Great wishlist idea. I uploaded the patch for implementing the check against the etag HMAC. As for verifying keys used for user-metadata, as you know, there is more discussion to be had in order to select some encrypted/HMAC'd magic value to the key id metadata.

IMHO, we are able to safely store off the HMAC of the etag because that value is not very sensitive. But when trying to think about persisting something new for a key verification check tends to lead to persisting data that we don't want to be in the business of persisting. I realize that some systems persist a hash of the key itself for verification purposes, but a determinate solution on a key means that you can tell when two are identical. Anyway, I don't want to get into all the thoughts here, but just wanted to give an example to communicate why I think there should be more than one patch for this.

Given that our user metadata is now encrypted with the same object key as the body wrapping and etag encryption, this check covers validation as the code stands today. This added check could be merged fairly quickly if separate, as compared to the probably more controversial solution that will most likely require persisting a new value.