Packaging lib/string/ as a standalone library.

[alejandro-colomar]

@hallyn , @ikerexxe , @thesamesam

I think it would be a good idea to export the string library we have here, so that other programs can use it (similar to how we have the libsubid library).

Can we tweak the build system to produce a libstring.so library and an installable set of header files from here?

It may take some time (possibly years), but if libc isn't going to provide these soon, I think we should do it ourselves.

[ikerexxe]

If the proposal is to keep the string code inside the shadow repository and expose it as a subpackage (matching how libsubid is handled), I'm fine with it. Technically, this is straightforward to implement in the build system and shouldn't cause issues for maintainers.

However, if the plan is to extract the code into an external repository and make shadow depend on it, we will likely face pushback from distribution maintainers. Introducing a new external dependency to a core security utility increases the supply chain attack surface and complicates security auditing. It also creates packaging overhead for distributions and complicates base-system bootstrapping. Furthermore, critical system utilities need to remain dependable in minimal or recovery environments, where extra dynamic dependencies increase the risk of broken binaries in emergency situations. Keeping libstring in-tree gives external consumers their shared library while keeping shadow lightweight and self-contained.

[alejandro-colomar]

If the proposal is to keep the string code inside the shadow repository and expose it as a subpackage (matching how libsubid is handled), I'm fine with it. Technically, this is straightforward to implement in the build system and shouldn't cause issues for maintainers.

However, if the plan is to extract the code into an external repository and make shadow depend on it, we will likely face pushback from distribution maintainers. Introducing a new external dependency to a core security utility increases the supply chain attack surface and complicates security auditing. It also creates packaging overhead for distributions and complicates base-system bootstrapping. Furthermore, critical system utilities need to remain dependable in minimal or recovery environments, where extra dynamic dependencies increase the risk of broken binaries in emergency situations. Keeping libstring in-tree gives external consumers their shared library while keeping shadow lightweight and self-contained.

Yup; I'm aware. That's why this time I proposed a keeping it in-tree (compared to liba2i, which distros have ignored so far). :)