summaryrefslogtreecommitdiff
path: root/test/integration/framework
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/integration/framework
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/integration/framework')
-rw-r--r--test/integration/framework8
1 files changed, 4 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"
}