check_stamp() function of apt.systemd.daily should not assume interval is a number
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apt (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Disco |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
[Impact]
Warning messages when using suffixes in intervals such as d for day
/usr/lib/
[Test case]
Create 99local in apt.conf.d with
APT::Periodic:
and run /usr/lib/
[Regression potential]
The fix replaces -eq 0 checks with = 0 checks which might have different behavior in case -eq also accepts some values as equal to 0 that are not literally 0 and that now no longer match. But then you'd have to do stuff like set the interval to "+0", and it seems unrealistic people do that.
[Original bug report]
In the second half of the function there is
# Calculate the interval in seconds depending on the unit specified
if [ "${interval%s}" != "$interval" ] ; then
elif [ "${interval%m}" != "$interval" ] ; then
elif [ "${interval%h}" != "$interval" ] ; then
else
fi
so, a variable might hold something like "1d", "100m", etc.
Yet in the first there is a condition
if [ "$interval" -eq 0 ]; then
debug_echo "check_stamp: interval=0"
# treat as no time has passed
return 1
fi
which treats the value as a number and leads to
/usr/lib/
description: | updated |
Changed in apt (Ubuntu Disco): | |
status: | Fix Committed → Won't Fix |
Oh, yes, but that's incomplete, there's a ton of other places that need adjusting too. In practice, the only non-number value supported is always.
Fixed in https:/ /salsa. debian. org/apt- team/apt/ commit/ 489da40d56075ef aa28bfdcfb7b02b 3bcc222323