On Sun, Jan 14, 2024 at 04:24:57PM +0100, Simon Josefsson wrote: > Isn't that what the text refers to? Vendoring and static linking are > two examples of the same problem that the security team may encounter.
We accept vendoring of autoconf/automake/gnulib distro wide. Please show practical problems with it? The result of autoconf and automake is not embedded into the produced binaries, so a security vulnerability can not go on. The vendoring of gnulib, well, is old and maybe you could show that it is a problem in the sources that have it, aka they don't handle security fixes and at the same time don't change the library. > The problem with dependencies are more obvious for Go/Rust code but I > think we always have had that problem anyway. Here the problem is embedded into the language oekosystem itself. It is not a choice of the software author to do static linking. > As for solutions, isn't the solution to both vendoring or statical > linking the obvious one? You will have to rebuild all packages that > contain the security vulnerability. I asked for practical solutions, not theoretical ones. We don't have a suitable way to rebuild all packages just because right now. > Maybe I'm missing how these two problems result in different problems > for the security team? You did not show that autoconf/automak/gnulib is a problem at all. And a => b with a false gives no answer. Bastian -- Spock: The odds of surviving another attack are 13562190123 to 1, Captain.
