Remove failed trusted signature instead of index on IMS hit

While passing the combi Release and Release.gpg to the gpgv method for
verification the filename of Release is placed where usually Release.gpg
is assumed in the rest of the code. The "usual" cases like passing
verification and failing verification ending in an error are taking care
of this, but the code path dealing with a failed verification, but
ignoring said failure (e.g. due to trusted=yes) was not which results in
the wrong file being removed later on (in case the index happens to be
unmodified since the last update call) leading us into the abyss of
strange failures (fixed in the previous commit) were nothing should have
changed.

This is not a security issue in this form as the repository needs to fail
verification & the user forcing apt to ignore the failure and carry on
anyhow. It does show however how complicated the code and its various
interconnected paths can become.

Reported-By: Val "pinkieval" Lorentz on IRC

1 files changed, 2 insertions, 0 deletions

diff --git a/test/integration/test-apt-update-repeated-ims-hit b/test/integration/test-apt-update-repeated-ims-hit
index 8630ff5ee..74d46b31b 100755
--- a/test/integration/test-apt-update-repeated-ims-hit
+++ b/test/integration/test-apt-update-repeated-ims-hit
@@ -53,11 +53,13 @@ testfailure grep 'aptarchive_Release.gpg$' lists.before
 for i in $(seq 1 3); do
 	msgmsg 'Running update again does not change result' "$i"
 	testwarningmsg "$GPGERROR" apt update
+	testfileequal lists.before "$(listcurrentlistsdirectory)"
 done
 
 find rootdir/var/lib/apt/lists -name '*Release*' -delete
 msgmsg 'Running update with a repository gaining hashsums'
 testwarningmsg "$GPGERROR" apt update
+testfileequal lists.before "$(listcurrentlistsdirectory)"
 
 changetowebserver
 find aptarchive -name '*Release*' -delete