[v3.4.15] Release Archive Mismatch with SHA256SUMS, Raw .tar Uploaded without GZIP

[hswong3i]

For https://github.com/etcd-io/etcd/releases/tag/v3.4.15, https://github.com/etcd-io/etcd/releases/download/v3.4.15/SHA256SUMS show as below:

$ curl -skL https://github.com/etcd-io/etcd/releases/download/v3.4.15/SHA256SUMS
c596709069193bffc639a22558bdea4d801128e635909ea01a6fd5b5c85da729  etcd-v3.4.15-darwin-amd64.zip
3797ab06bebe218d5636fa0fb5d127adcace4ca4c1eed959d361dd5b4ba84c1d  etcd-v3.4.15-linux-amd64.tar.gz
3d213ba76b3004de786e3a033da0625c16addc6338f130e23f0521e699c36ef0  etcd-v3.4.15-linux-arm64.tar.gz
5b3e2e9d894c582807a4d7c7c39d43b6fb1a9c1bb2e1543f3e5fa4800c2cf775  etcd-v3.4.15-linux-ppc64le.tar.gz
f25c052d3a36582edbf11a396d617b6f1e3022d90d070a972d83fbb64f932a40  etcd-v3.4.15-windows-amd64.zip

BTW, release archive is wrongly named as .tar but not .tar.gz and so checksum mismatch :-(

• https://github.com/etcd-io/etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-amd64.tar
• https://github.com/etcd-io/etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-arm64.tar
• https://github.com/etcd-io/etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-ppc64le.tar

UPDATE: actually the .tar is not wrongly named, IT IS a .tar file without gzip, e.g.:

$ curl -skL https://github.com/etcd-io/etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-amd64.tar | sha256sum 
817addc542d5ecf94b779f09a51fc6fd1e64cd976030eb2db28d38ccf1626a52  -
$ curl -skL https://github.com/etcd-io/etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-arm64.tar | sha256sum 
5186007b72355a385c1dd5a01f92c958d09d3067c6546569bc0362bd654899f7  -
$ curl -skL https://github.com/etcd-io/etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-ppc64le.tar | sha256sum 
817e07b2f865a0994d6ccbc155e777f936f373a595745181e53c10f163fd6db9  -
``

[hswong3i]

@gyuho shall we get the release archive fixed with .tar.gz?

[hswong3i]

@gyuho after 20 days without fixing with .tar.gz, finally I just simply gzip -9 etcd-v3.4.15-linux-amd64.tar and upload it as https://github.com/alvistack/etcd-io-etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-amd64.tar.gz, for my own use in Ansible Role, see:

• alvistack/ansible-role-etcd@7b9367e

[mritd]

Is there any progress? My CI workflow failed because of this. I want to know if there are any compatible fixes?

[ptabor]

I manually compressed that tars and pushed to: https://github.com/etcd-io/etcd/releases/tag/v3.4.15.
I updated the SHA256SUMS as my gzip produced different checksums of the compressed files (different version or options).
The orginal SHA256SUMS got renamed to SHA256SUMS.old

[mritd]

Thank you for your work, it's okay now 😁

[gyuho]

My apologies! Thanks for the report!

[hswong3i]

@ptabor thank you very much ;-)

[Stephan-Walter]

hm... the new archives have very different sizes. Is this only for me suspicious?

Or is this just a hint, that the .tar files are without any compression?

[ptabor]

I used the default compression (gzip *.tar). I didn't used heavy gzip -9 compression.

[Stephan-Walter]

I mean, that the actual archives are much smaller than the incorrect created ones from 3.4.15.

etcd-v3.4.15-linux-amd64.tar   44.7 MB
etcd-v3.4.15-linux-amd64.tar.gz 16.6 MB

So 16.6 vs 44.7MB. So I would assume, that within the .tar no compression at all was used, or that there is something within, that shouldn't be there. In general I would setup a secure system to check the content of the two archives, but unfortunately I have no time for that right now.

[ptabor]

tar is uncompressed format. Please see: https://en.wikipedia.org/wiki/Tar_(computing)

Fill free to decompress 'etcd-v3.4.15-linux-amd64.tar.gz' and verify that it had the same checksum as etcd-v3.4.15-linux-amd64.tar

[Stephan-Walter]

yes I know, but names are just names. So you don't know if the name was just wrong, the Checksum or it seems to be the case now the compression wasn't used.

From my point of view, a few more words would have been good, since this is at least for me a trust problem. Maybe I am paranoid. But yeah, too many hacked systems within the last year within our line of business....