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: 1.0.0_pre20191002222144-r0
, 1.0.0_pre20210530193627-r0
.
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 & 0xffffffff
is(int)0x1583de40
, which is positive. -
20210530193627 & 0xffffffff
is(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 int
?
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