You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@m-blaha suggests that all calculated checksums should be eligible for caching, if caching == TRUE when calling lr_checksum_fd_compare. I tend to agree, but the cache key does not indicate which hash algorithm was used, so we need to resolve that first. If we don't, an md5 checksum would be cached, which would never match a sha256 for example.
The text was updated successfully, but these errors were encountered:
The keys (xattrs names) has changed recently (see 7a7cd44)
Originally the cache key was something like user.Zif.MdChecksum[123456] where 123455 was mtime of the file. This caused problems precisely because the hash algorithm was not stored. Now we use two keys instead - user.Librepo.checksum.mtime for the timestamp and a set of user.Librepo.checksum.HASH_TYPE for actual checksums. HASH_TYPE is most often sha256, but could vary according the hash used in particular repositories.
@m-blaha : awesome - I didn't pick up on the keys being fixed in this way before. Now that this is resolved, what is your opinion? Is this safe to implement?
See https://github.com/rpm-software-management/librepo/pull/234/files/2743583e444d745526e9bb8fad249ce6ea08e0f9#r594141462 for context
@m-blaha suggests that all calculated checksums should be eligible for caching, if
caching == TRUE
when callinglr_checksum_fd_compare
. I tend to agree, but the cache key does not indicate which hash algorithm was used, so we need to resolve that first. If we don't, an md5 checksum would be cached, which would never match a sha256 for example.The text was updated successfully, but these errors were encountered: