Version length limits
We ran into an issue where
apk add would choose older versions of a locally built package over newer versions.
The packages were versioned using timestamps with one-second precision, like this:
apk add considers the older version (from 2019) to be the latest one. Explicitly requesting the 2021 version causes
apk add to claim that the package "will be DOWNGRADED".
The reason for this is that the loop at https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/version.c#L95 will try to parse the version number numerically, but it puts it in a 32 bit
int and it does not detect overflow.
20191002222144 & 0xffffffffis
(int)0x1583de40, which is positive.
20210530193627 & 0xffffffffis
(int)0xa17910db, which is negative.
And so it chose the 2019 version as being the "newest".
Would it be possible to use
long, instead of
Also, if versions have a size limit, it would be great if this limit were checked up front, perhaps when
APKINDEX is being built. I noticed that
apk version --check does not report a problem with these versions, even though they both overflow later on:
# apk version --check 1.0.0_pre20210530193627-r0 && echo success success