summaryrefslogtreecommitdiff
path: root/test/integration/test-cve-2013-1051-InRelease-parsing
diff options
context:
space:
mode:
authorDavid Kalnischkies <david@kalnischkies.de>2015-04-12 17:08:46 +0200
committerDavid Kalnischkies <david@kalnischkies.de>2015-04-19 01:13:10 +0200
commitba6b79bd0090077724fa1272ea4d3a31706fcd5a (patch)
tree020931e0a2e5316e2832b7c7bd4ee6d619a6db2d /test/integration/test-cve-2013-1051-InRelease-parsing
parent295d848b37e1211feae5d37db27f148dc9ea3d38 (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/test-cve-2013-1051-InRelease-parsing')
0 files changed, 0 insertions, 0 deletions