Tracing binaries statically linked against vulnerable libs

[Andrew Pantyukhin]

On 10/14/06, Kris Kennaway <kris at obsecurity.org> wrote:
> On Fri, Oct 13, 2006 at 05:18:57PM +0400, Andrew Pantyukhin wrote:
> > Anyway, maybe portmgr could issue some kind of a policy
> > about this. I.e. (1) use {build,run}_depends instead of lib_
> > when you depend on a port providing both shared and
> > static libraries, but link statically; (2) make an effort to
> > encourage dynamic linking - try to provide only shared
> > libs in new ports, remove unused static ones from old
> > ones, and so on.
>
> (1) is just a statement of correct behaviour, no need for a policy
> about it (it could be clarified in the porters handbook if needed).
> (2) could also be added to the porter's handbook as a recommendation-
> I don't think we need a formal proclamation of policy about it.

Again, the problem is tracking what ports are affected by
vulnerabilities. Making static linking optional will only help
if pkgname is changed in a mandatory fashion. Moreover
there are ports with mixed linking (afaik, mplayer is one
of them).

So if we go easy on maintainers, then we should either
put sufficient human resources to exploring security
issues manually in each particular case, or in absence
thereof, act paranoid and mark a lot of ports vulnerable.

> P.S. I can provide a list of static binaries in ports if anyone wants
> to work on fixing them.

It would be great if we could find a way to make a list
of what particular libraries each port is statically linked
against.

Meanwhile, I'll try to ask around as to how they deal with
it in other projects.

Thanks!