GitLab

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