pkg_libchk: a missing library is not detected

Mel Flynn mel.flynn+fbsd.ports at mailing.thruhere.net
Tue Jun 16 19:01:24 UTC 2009


On Tuesday 16 June 2009 07:34:47 Dominic Fandrey wrote:
> Mel Flynn wrote:
> > On Monday 15 June 2009 02:55:09 Dominic Fandrey wrote:
> >> Sorry for the late reply, this was auto-sorted into the ports@ mails
> >> and drowned there.
> >>
> >> Boris Samorodov wrote:
> >>> As I understand pkg_upgrade does not preserve old libraries at
> >>> /usr/local/lib/compat?
> >>
> >> That's true. I consider this common approach a security risk.
> >
> > It is a service interruption to delete libraries that are still used and
> > this can also lead to security problems.
> > However, pkg_upgrade cannot ever hope to fix this problem, because the
> > buildservers do not unconditionally rebuild packages that mention the
> > upgraded port in LIB_DEPENDS, therefore it is better to leave these
> > shared libraries around.
>
> To me something not working seems to be less of a security problem than
> linking to a vulnerable library.

Depends what is not working. If it's the monitoring software, do you still 
agree?
Also, a library with a vulnerability does not always constitute an exploitable 
library for the way a running vital application uses it. Either way, I don't 
think you should unconditionally interrupt service, because you think yours is 
the right way. It should be optional and because of your own conviction, you 
could choose to make the default "security over service".

> >> To ensure that you get the newest packages wipe
> >> /usr/ports/packages/All.
> >
> > Erm, the download time associated with that approach doesn't really speed
> > up things, nor does it guarantee that you will have working binaries if
> > the port maintainer forgot to version bump a port.
>
> Well, you don't ever need them again after having them installed once, so I
> don't see the problem.

True I guess for most cases, but if that's true, then why remove them if 
you're not ever going to download them twice?

> And at least from pointyhead I've never head
> broken linking, even when the package was not version bumped, so I think
> there's some kind of human intervention, or I was lucky.

Luck. The app linking to the old library will have a dependency on the old 
version. pkg_add will find the origin, issue a warning about "app-1.0 needing 
lib-0.1 but lib-0.2 is installed" and proceed. app will not start, because of 
the missing library.

> Proper version bumping solves both problems, though and it is rarely
> forgotten lately. So the issue is much smaller, now than it would have been
> a couple of years ago. Also I do not see a way for my tool to handle this
> in any acceptable way. If you've got an idea, go ahead and tell me. I
> actually want to deal with as many problems as possible without user
> intervention. It's about making life easier, after all.

You can't without the buildservers providing hashes for the packages (to 
detect if a package has been repacked) or in less good case checking lastmod 
time and size plus the buildservers rebuilding dependents.
-- 
Mel


More information about the freebsd-ports mailing list