Joerg Jaspert wrote: > Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the > tools that can't deal with this. The latter two are serious enough to > keep the change away from oldstable forever, and stable at least until > after next point release, should they get updated there. It's also desirable that stable's debootstrap be able to bootstrap unstable chroots. > > Also, I'll see about getting d-i generating some stronger checksum files > > now that it's been pointed out. Although I wonder if it would make more > > sense to generate those checksums on the server side. > > Well, the files currently come from the d-i builds. Makes sense, it > shows what the build host expects them to be, not what a *possible* > corruption during transport to us and unpack made them. How likely such > a corruption is is a different topic, but the theoretical possibility is > there. And we ARE using the MD5SUMS file when we accept the d-i tarballs > to check if it actually matches, so I think we should keep that. The debian-installer .changes file should list the byhand tarball with sha1 and sha256 just like any other file in a changes file. Those would be the right checksums to verify, not the md5sums inside the tarball. Also, it seems like the Releases file is already including sha1 and sha256 for all the d-i files. -- see shy jo
Attachment:
signature.asc
Description: Digital signature