On Fri, 2022-01-21 at 13:55 -0500, Theodore Ts'o wrote: > Can we have better automated tooling, either in Lintian, or in when > source packages are rebuilt, that can take care of this? > > The other thing that's perhaps considering here is that unfortunately, > there are some upstreams that are extremely irresponsible with library > ABI backwards compatibility, where they bump the SONAME essentially at > every release. I recall one extreme case a few years ago where there > were over ten(!) SONAME bumps for a particular library over 12 months. You could avoid NEW for these SONAME bumps by using a single binary package and ensuring that the symbols/shlibs depend on the right version ranges. Or add Provides libfoo-abi-N or libfoo-abi (= N) and have the symbols and or shlibs generate dependencies on that. > But if we're going to do that, then we could also just support static > libraries, and just rebuilt all of the pacakges that link statically > with libshaky, thus solving the security argument for shared > libraries. This also avoids the fairness problem where some packages > are reguarly going through ftpmaster review, and others aren't... In the past I've suggested a solution to static linking and binary packages containing source could be to have a service scanning every binary package for static/source files (.a, Rust, Golang etc), noting the relevant package/version tuples and then searching the buildinfo files for binary packages that built with those packages installed and automatically rebuilding affected packages, or having a service that would let you manually rebuild packages affected by security issues. https://wiki.debian.org/StaticLinking In addition there are toolchain changes coming in at least Golang and possibly GCC (pushed by Fedora IIRC) for adding source file/package information into generated binaries. The scanning/buildinfo/rebuilding idea would produce more builds than strictly necessary, but perhaps the coming toolchain changes could be helpful in filtering down the lists. Ultimately the best option would be for all build toolchains to have instrumentation that enables us to completely graph the flow of source data to -dev binary packages etc to final binary packages. Perhaps each build system, compiler etc would communicate with a daemon that would collect the file/etc paths/hashes/etc, map those back to package, version tuples and upload those to dak in buildgraph files. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part