#1062110 android-libboringssl: identified for time_t transition but no ABI in shlibs

Package:
android-libboringssl
Source:
android-libboringssl
Description:
Google's internal fork of OpenSSL for the Android SDK
Submitter:
Steve Langasek
Date:
2024-05-21 08:21:03 UTC
Severity:
normal
#1062110#5
Date:
2024-01-31 11:32:01 UTC
From:
To:
Package: android-libboringssl
Version: 14.0.0+r11-4
Severity: serious
User: debian-arm@lists.debian.org
Usertags: time-t

Hi Roger,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
android-libboringssl as a package shipping a library whose ABI changes on
32-bit architectures with 64-bit time_t.

However, android-libboringssl's shlibs file declares a dependency on a
library package name that contains no ABI information:

$ cat DEBIAN/shlibs
libcrypto 0 android-libboringssl (>= 14.0.0+r11)
libssl 0 android-libboringssl (>= 14.0.0+r11)
$

It is therefore not obvious that we should rename the package to
'android-libboringsslt64' as part of this transition.

Looking at the archive, there are packages built from separate source
packages, including adb and fastboot, that depend on this library.

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs.
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures (upgrading android-libboringssl without also
upgrading adb, fastboot, etc) will result in ABI skew and may result in
broken behavior.

Thanks,

#1062110#12
Date:
2024-05-21 08:11:32 UTC
From:
To:
control: severity -1 normal

Thanks for reporting!  In the Android Tools case, the shared libs and packages
that use them are packaged together, often from the same source package, so I
can't see why we'd need special versions of it. And when we need to, we can use
strictly versioned depends, so it should be fine. I'm going to set the bug to
normal for now.