Skip to main content

abi-compliance-checker & dh / cdbs integration

dh-autoreconf is an amazing addon for running autoreconf, I just love it.
abi-compliance-checker is an amazing tool for tracking API/ABI.
Wouldn't it be great to glue abi-compliance-checker into dh / cdbs packaging?!
 abi-compliance-checker (1.98.8-1~exp1) experimental; urgency=low
 .
   * New upstream release
   * Add dh_acc to generate and compare library dumps at build time,
     together with addons for dh(7) and cdbs.

   * Bump standards version, bump debhelper to 9, use 3.0 (quilt) format,
     update Vcs-Svn field to canonical form, remove obsolete
     DM-Upload-Allowed.
   * Apply a patch to allow suffixes on a-c-c abi dumps.
Horay! So how does one use it?

  • build-depend on dh-acc
  • In your debian/rules
    • call dh_acc somewhere appropriate
    • dh $@ --with acc
    • include /usr/share/cdbs/1/rules/acc.mk
  • In your debian/libpackage-dev.acc
    • Write a abi-compliance-checker descriptor (no need to include version)
  • Build your package
  • Copy the generated /usr/lib/$(multiarch)/dh-acc/*.abi.tar.gz as ./debian/lib-package-dev.abi.tar.gz.ARCH
  • Now at each build ABI/API checks will be executed and compat reports will be generated
An example xml descriptor for libapt-pkg-dev is:
<?xml version="1.0" encoding="utf-8"?>
<descriptor>
<headers>
  ./build/include/apt-pkg/
</headers>
<libs>
  ./build/bin/
</libs>
<skip_types>
  SubstVar
</skip_types>
</descriptor>
I wonder if things can be improved, for example:
  • For trivial packages, don't require .acc at all & simply point abi-compiance-checker at ./debian/tmp/
  • I think logs currently pollute the unpacked source package
  • Multiple "base" ABI need checking. E.g. given versions A, B, C one can introduce a new symbol in B and drop it in C. Both B & C are compatible with A, but C is not compatible with B, thus an API/ABI break got introduced into the distribution if all A,B,C were ever published in the archive.
  • Maybe run these as DEP-8 autopkgtests as well?
On a wider scope of things abi-compliance-checker allows to create "system" abi dumps & also check applications for ABI/API compliance. For example, one could scan deb packages to see if they are still compatible between major Debian Releases for some known install type (e.g. a default full Gnome Desktop), or we could scan proprietary packages to see if they are compatible (e.g. games delivered via Steam by Valve to multiple Ubuntu releases), and we can continuously monitor OS ABI to make sure we don't unknowingly break it with security and bugfix updates.

Please, play around with dh-acc and let me know what you think =)

Comments

Popular posts from this blog

Achieving actually full disk encryption of UEFI ESP at rest with TCG OPAL, FIPS, LUKS

Achieving full disk encryption using FIPS, TCG OPAL and LUKS to encrypt UEFI ESP on bare-metal and in VMs Many security standards such as CIS and STIG require to protect information at rest. For example, NIST SP 800-53r5 SC-28 advocate to use cryptographic protection, offline storage and TPMs to enhance protection of information confidentiality and/or integrity. Traditionally to satisfy such controls on portable devices such as laptops one would utilize software based Full Disk Encryption - Mac OS X FileVault , Windows Bitlocker , Linux cryptsetup LUKS2 . In cases when FIPS cryptography is required, additional burden would be placed onto these systems to operate their kernels in FIPS mode. Trusted Computing Group  works on establishing many industry standards and specifications, which are widely adopted to improve safety and security of computing whilst keeping it easy to use. One of their most famous specifications them is TCG  TPM 2.0 (Trusted Platform Module). TPMs are now...

Security-only OpenSSL tarball releases for CVE-2026-2673

On Friday May the 13th OpenSSL project has published advisory details for  CVE-2026-2673 . The CVE is treated as non-important by the project. The patches are only provided as commits on the stable branches. No git tag, no precise fixed version, and no source tarballs provided. The patches that were merged to openssl-3.5 and openssl-3.6 branches were not based on top of the last stable point release and did not split code changes & documentation updates. It means that cherry-picking the commits referenced in the advisory will always lead to conflicts requiring manual resolution. It is not clear if support is provided for snapshot builds off the openssl-3.5 and openssl-3.6 branches. As the builds from the stable branches declare themselves as dev builds of the next unreleased point release. For example, in contrast to projects such as vim and glibc, with every commit to stable branches explicitly recommended for distributors to ship and is supported. I have requested OpenSSL ups...

Encrypt all the things

xkcd #538: Security Went into blogger settings and enabled TLS on my custom domain blogger blog. So it is now finally a https://blog.surgut.co.uk  However, I do use feedburner and syndicate that to the planet. I am not sure if that is end-to-end TLS connections, thus I will look into removing feedburner between my blog and the ubuntu/debian planets. My experience with changing feeds in the planets is that I end up spamming everyone. I wonder, if I should make a new tag and add that one, and add both feeds to the planet config to avoid spamming old posts. Next up went into gandi LiveDNS platform and enabled DNSSEC on my domain. It propagated quite quickly, but I believe my domain is now correctly signed with DNSSEC stuff. Next up I guess, is to fix DNSSEC with captive portals. I guess what we really want to have on "wifi" like devices, is to first connect to wifi and not set it as default route. Perform captive portal check, potentially with a reduced DNS server capabil...