Hi, Looking at some DIGESTS files for released media (stages and isos) i see that the BLAKE2 Hashes have an full path included while the SHA512 only contain the filenames. I guess this is not intended and there should only be the filenames included (without the paths). I noticed this because my download scripts (which do check the hashes) started to fail recently.
Forgot to mentioned, below some digests files (links) who contain these paths: stage3-musl: https://mirrors.163.com/gentoo//releases/amd64/autobuilds/current-stage3-amd64-musl/stage3-amd64-musl-20210801T170533Z.tar.xz.DIGESTS install-amd64-minimal: https://mirrors.163.com/gentoo//releases/amd64/autobuilds/20210801T170533Z/install-amd64-minimal-20210801T170533Z.iso.DIGESTS
Thanks! That's odd. Do you know when this behavior started?
(In reply to Matt Turner from comment #2) > Thanks! > > That's odd. Do you know when this behavior started? I was just wondering about this last night after o32 stages completed on one of my build machines. I have an archive of builds and their digests going back a few years (at least to 2017). Give me some time later to unpack them and see how far back BLAKE2 hashes were done and included full paths.
(In reply to Joshua Kinard from comment #3) > (In reply to Matt Turner from comment #2) > > Thanks! > > > > That's odd. Do you know when this behavior started? > > I was just wondering about this last night after o32 stages completed on one > of my build machines. I have an archive of builds and their digests going > back a few years (at least to 2017). Give me some time later to unpack them > and see how far back BLAKE2 hashes were done and included full paths. The last stage builds I did in March 2020 did not use BLAKE2 hashes, only SHA512 and Whirlpool. The DIGESTS file only has the stage tarball filename and not a full path. So likely this bug was introduced when BLAKE2 support was introduced and made a default.
hosts which use -9999 catalyst seem to generate correct digests (only basename without path). afaik amd64 hosts use versioned catalyst. maybe something went wrong backporting blake2b support to stable branch?
I've checked my logfiles. For me it seems it all startet on the 04.07.2021. The first file which had this path included was /var/tmp/catalyst/builds/default/stage3-i686-systemd-20210703T190603Z.tar.xz FYI: My script only downloads the x86 and amd64 iso's + the stage3 images for this arches (inclusive systemd variant)
*** Bug 832731 has been marked as a duplicate of this bug. ***
Fixed by dropping the blake2 hash (on amd64, x86, m68k, alpha, riscv).
(In reply to Andreas K. Hüttel from comment #8) > Fixed by dropping the blake2 hash (on amd64, x86, m68k, alpha, riscv). Was this fixed directly in Catalyst, or just on the DIGESTS files on the mirrors for the listed archs?
(In reply to Georgy Yakovlev from comment #5) > hosts which use -9999 catalyst seem to generate correct digests (only > basename without path). > > afaik amd64 hosts use versioned catalyst. (In reply to Joshua Kinard from comment #9) > > Was this fixed directly in Catalyst, or just on the DIGESTS files on the > mirrors for the listed archs? By dropping blake2 from the config on the one host which uses stable catalyst.
(In reply to Andreas K. Hüttel from comment #10) > (In reply to Georgy Yakovlev from comment #5) > > hosts which use -9999 catalyst seem to generate correct digests (only > > basename without path). > > > > afaik amd64 hosts use versioned catalyst. > > > (In reply to Joshua Kinard from comment #9) > > > > Was this fixed directly in Catalyst, or just on the DIGESTS files on the > > mirrors for the listed archs? > > By dropping blake2 from the config on the one host which uses stable > catalyst. Okay, so versioned/stable catalyst is still affected, then. I'll check later for a bug against stable and follow that, and if I can't find one, open a new one so that stable will eventually get a fix. Thanks!
