diff options
author | David Kalnischkies <david@kalnischkies.de> | 2015-04-12 17:08:46 +0200 |
---|---|---|
committer | David Kalnischkies <david@kalnischkies.de> | 2015-04-19 01:13:10 +0200 |
commit | ba6b79bd0090077724fa1272ea4d3a31706fcd5a (patch) | |
tree | 020931e0a2e5316e2832b7c7bd4ee6d619a6db2d /test/integration/Packages-releasefile-verification | |
parent | 295d848b37e1211feae5d37db27f148dc9ea3d38 (diff) |
a hit on Release files means the indexes will be hits too
If we get a IMSHit for the Transaction-Manager (= the InRelease file or
as its still supported fallback Release + Release.gpg combo) we can
assume that every file we would queue based on this manager, but already
have locally is current and hence would get an IMSHit, too. We therefore
save us and the server the trouble and skip the queuing in this case.
Beside speeding up repetative executions of 'apt-get update' this way we
also avoid hitting hashsum errors if the indexes are in fact already
updated, but the Release file isn't yet as it is the case on well
behaving mirrors as Release files is updated last.
The implementation is a bit harder than the theory makes it sound as we
still have to keep reverifying the Release files (e.g. to detect now expired
once to avoid an attacker being able to silently stale us) and have to
handle cases in which the Release file hits, but some indexes aren't
present (e.g. user added a new foreign architecture).
Diffstat (limited to 'test/integration/Packages-releasefile-verification')
0 files changed, 0 insertions, 0 deletions