Package: src:aptly Version: 1.4.0+ds1-2 Severity: normal Control: found -1 1.3.0+ds1-2 Control: tags -1 upstream fixed-upstream Control: forwarded -1 https://github.com/aptly-dev/aptly/issues/923
Hello, A year ago I found an issue with aptly with S3 backend: it relies on ETag always being the MD5 hashsum of a file, while it’s not necessarily true, as demonstrated in the comments to https://github.com/minio/minio/pull/9999: > The entity tag is a hash of the object. The ETag reflects changes only > to the contents of an object, not its metadata. The ETag may or may not > be an MD5 digest of the object data. Whether or not it depends on how > the object was created and how it is encrypted as described below: > > Objects created by the PUT Object, POST Object, or Copy operation, > or through the AWS Management Console, and are encrypted by SSE-S3 or > plaintext, have ETags that are an MD5 digest of their object data. > > Objects created by the PUT Object, POST Object, or Copy operation, > or through the AWS Management Console, and are encrypted by SSE-C or > SSE-KMS, have ETags that are not an MD5 digest of their object data. > > If an object is created by either the Multipart Upload or Part Copy > operation, the ETag is not an MD5 digest, regardless of the method > of encryption. I have proposed changes fixing this in a pull request that’s been merged today. It’s quite self-contained and only affects the S3 backend. The idea is to store the MD5 of an object in a separate metadata field as well to make sure it isn’t lost, so when the value returned in ETag clearly doesn’t look like a valid MD5 hash (length isn’t exactly 32 characters), this metadata field is used instead. See https://github.com/aptly-dev/aptly/pull/924 for more details. Please consider applying these patches and shipping them in Bullseye. Thanks! -- Cheers, Andrej
