From f2f8e89f08cdf01c83a0b8ab053c65329d85ca90 Mon Sep 17 00:00:00 2001 From: David Kalnischkies Date: Wed, 26 Jul 2017 18:35:42 +0200 Subject: fail early in http if server answer is too small as well Failing on too much data is good, but we can do better by checking for exact filesizes as we know with hashsums how large a file should be, so if we get a file which has a size we do not expect we can drop it directly, regardless of if the file is larger or smaller than what we expect which should catch most cases which would end up as hashsum errors later now a lot sooner. --- test/integration/test-pdiff-usage | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'test/integration/test-pdiff-usage') diff --git a/test/integration/test-pdiff-usage b/test/integration/test-pdiff-usage index 6a6f13b1b..53586ef32 100755 --- a/test/integration/test-pdiff-usage +++ b/test/integration/test-pdiff-usage @@ -298,9 +298,7 @@ SHA256-Patches: SHA256-Download: d2a1b33187ed2d248eeae3b1223ea71791ea35f2138a713ed371332a6421f467 197 2010-08-18-2013.28.gz $(sha256sum "${PATCHFILE}.gz" | cut -d' ' -f 1) $(stat -c%s "${PATCHFILE}.gz") $(basename "${PATCHFILE}.gz")" > "$PATCHINDEX" - # needs to look like a valid command, otherwise the parser will fail before hashes are checked - echo '1d' > "$PATCHFILE" - cat "$PATCHFILE" | gzip > "${PATCHFILE}.gz" + breakfiles "$PATCHFILE" "${PATCHFILE}.gz" generatereleasefiles '+1hour' signreleasefiles testsuccess apt update "$@" -- cgit v1.2.3