Re: Hashsum mismatch prevention strategies
* David Kalnischkies <kalnischkies@gmail.com> [120511 03:03]:
> Option A is that each mirror (if it chooses to do it) builds a big "index" of
> hashsum-named hardlinks to the "old" location of the file. Given a
> repository like this:
> unstable/InRelease
> unstable/main/binary-amd64/Packages
> unstable/main/binary-i386/Packages
> this would mean that we e.g. have a
> unstable/by-hash/sha256/bbbbb… -> unstable/main/binary-amd64/Packages
> unstable/by-hash/sha256/ccccc… -> unstable/main/binary-i386/Packages
> (Imagine this being done for e.g. md5 and sha1 hashes, too)
>
> A client like apt would then request the InRelease file as usual and then take
> the hashes it can extract out of it to request the other files it needs.
If this is implemented, please add some field in InRelease to denote
those files are there and do not make any program look for those files
unless that flag is found. (In the past apt-get often got support for
things not yet in the Release files thus guessing there availability
by trying to download them unconditionally. I think that is a mistake
that should not be repeated).
> On a mirrorsync the indexes files will be updated and get new hashes,
> but a new client still working with the old InRelease file will still get
> the old indexes files based on their hash.
When reading this I thought you meant that repository generation tools
will always generate those files and keep older versions and the client
will always download the hashed names, but then:
> As the mirror is it who generates the by-hash he would be free to not do it
> and/or to store old indexes for a self-chosen length of time. Given that a
> client needs to fallback for every file it can't get by-hash to request it
> by its "old" location -- and in the long run it has to check for different
> checksums as we move to stronger hashes over time.
Urgs, the mirror should generate them? I do not think that this is a
good idea at all.
> Option B would be to introduce "versioned" components. The InRelease file
> would include a tag specifying a version (a good version would e.g. be
> the date(time) of the creation) for the components it includes.
>
> A client would then not request files under $component but under
> $component-$version, e.g. instead of main it would be main-2012-05-10.
> An old client would "just" follow the link from main to its current version
> off-spin similar to how unstable links to sid. As the InRelease includes
> a new tag a new client will need to use this "feature" we don't need a
> fallback.
How about making that a subdirectory instead?
i.e.
2012-05-10/main
2012-05-10/contrib
2012-05-10/non-free
main -> 2012-05-10/main
contrib -> 2012-05-10/contrib
non-free -> 2012-05-10/non-free
I see both suggestions involve symlinks. Do all (or at least all
official mirrors) support symlinks?
> So, in short: What do you think? Is there an option C or are there
> features/problems in A or B which i have omitted/overseen?
One could also look into the client side: a InRelease file is not that
big, so if the hashes do not compare, one could reload the InRelease
file to see if anything changed.
Bernhard R. Link
Reply to: