summaryrefslogtreecommitdiff
path: root/test
diff options
context:
space:
mode:
authorDavid Kalnischkies <david@kalnischkies.de>2023-03-04 11:55:34 +0100
committerDavid Kalnischkies <david@kalnischkies.de>2023-03-04 13:07:00 +0100
commit937221fde2a5ca989a0b80728cd3ba3639f9f20e (patch)
tree397fe4f1153fb9493bf97e95d00bea9ac4c06b7e /test
parente90ba0afa2a27ecea792e8039b2917ec55647548 (diff)
Do not store trusted=yes Release file unconditionally
A source marked with trusted=yes can still fail verification of the Release file, mostly for Date related issues, like being too new or too old, which have other options to force them in. The update code was not using the Release file (which was a InRelease file but failed verification – which was overridden by trusted=yes) as intended, but it marked it for storage, so that this "bad" Release file would end up being moved into lists/, which is bad as the indexes it refers to aren't updated while the next update run assumes that the indexes are in the state the Release file claims them to be in. Fixed simply by making the storage conditional on the usage as intended, which also resolves a second issue: The verification can also detect that a Release file we got is older than what we already have to avoid down- grade attacks. The more likely explanation is a slightly outdated mirror in a rotation/CDN through, so this gets the silent treatment to avoid scaring users by handling it as if we had got the same Release file we already have stored locally, removing the freshly received older file in the process alongside setting some variables. Those variables were already modified in the trusted=yes case though resulting in the stored Release file being removed instead. Not modifying the variables too early resolves this problem as well. Both seem to exist since at least 2015 as traces are visible in 448c38bdcd already, which shuffled lots of code around including the bad ones, but as we are in trusted=yes land, security is of no concern here, this "just" leads to failed pinning, hashsum mismatches and other strange problems in follow-up calls depending on how out of sync the Release file (if its still present) is with the rest of the trusted data. Reported-By: Dima Kogan <dkogan@debian.org> on IRC Tested-By: Dima Kogan <dkogan@debian.org>
Diffstat (limited to 'test')
-rw-r--r--test/integration/framework8
-rwxr-xr-xtest/integration/test-releasefile-date-older28
2 files changed, 32 insertions, 4 deletions
diff --git a/test/integration/framework b/test/integration/framework
index d50b63518..264c228d0 100644
--- a/test/integration/framework
+++ b/test/integration/framework
@@ -1204,16 +1204,16 @@ generatereleasefiles() {
msgninfo "\tGenerate Release files for flat… "
aptftparchiverelease ./aptarchive > aptarchive/Release
fi
+ if [ -n "$VALIDUNTIL" ]; then
+ sed -i "/^Date: / a\
+Valid-Until: $(date -u -d "$VALIDUNTIL" -R)" $(find ./aptarchive -name 'Release')
+ fi
if [ -n "$DATE" -a "$DATE" != "now" ]; then
for release in $(find ./aptarchive -name 'Release'); do
sed -i "s/^Date: .*$/Date: $(date -u -d "$DATE" -R)/" "$release"
touch -d "$DATE" "$release"
done
fi
- if [ -n "$VALIDUNTIL" ]; then
- sed -i "/^Date: / a\
-Valid-Until: $(date -u -d "$VALIDUNTIL" -R)" $(find ./aptarchive -name 'Release')
- fi
msgdone "info"
}
diff --git a/test/integration/test-releasefile-date-older b/test/integration/test-releasefile-date-older
index e38ddc3c5..81c71ea9a 100755
--- a/test/integration/test-releasefile-date-older
+++ b/test/integration/test-releasefile-date-older
@@ -102,3 +102,31 @@ generatereleasefiles 'now' 'now + 2 days'
sed -i '/^Date: / d' $(find ./aptarchive -name 'Release')
signreleasefiles
testwarning aptget update
+
+# the repo is now signed by unknown key, but marked as trusted
+rm -rf rootdir/etc/apt/trusted.gpg.d
+sed -i -e 's#\(deb\(-src\)\?\) #\1 [trusted=yes] #' rootdir/etc/apt/sources.list.d/*
+
+msgmsg 'Forgot to disable in follow-up' 'Check-Date'
+rm -rf rootdir/var/lib/apt/lists
+generatereleasefiles 'now + 3 days' 'now + 7 days'
+signreleasefiles
+testfailure aptget update
+testwarning aptget update -o Acquire::Check-Date=no
+listcurrentlistsdirectory > listsdir.lst
+generatereleasefiles 'now + 5 days' 'now + 13 days'
+signreleasefiles
+testfailure aptget update
+testfileequal 'listsdir.lst' "$(listcurrentlistsdirectory)"
+testwarning aptget update -o Acquire::Check-Date=no
+testsuccess cmp "$(find aptarchive/ -name 'InRelease')" "$(find rootdir/var/lib/apt/ -name '*_Release')"
+
+msgmsg 'Force-Trusted InRelease file is silently ignored' 'new Date is before old Date'
+rm -rf rootdir/var/lib/apt/lists
+generatereleasefiles 'now' 'now + 7 days'
+signreleasefiles
+testwarning aptget update
+listcurrentlistsdirectory > listsdir.lst
+redatereleasefiles 'now - 2 days'
+testwarning aptget update
+testfileequal 'listsdir.lst' "$(listcurrentlistsdirectory)"