Date: Wed, 17 Jun 2009 01:08:52 +0200 From: Dominic Fandrey <kamikaze@bsdforen.de> To: Mel Flynn <mel.flynn+fbsd.ports@mailing.thruhere.net> Cc: Boris Samorodov <bsam@ipt.ru>, freebsd-ports@freebsd.org Subject: Re: pkg_libchk: a missing library is not detected Message-ID: <4A382604.9090206@bsdforen.de> In-Reply-To: <200906161101.22167.mel.flynn%2Bfbsd.ports@mailing.thruhere.net> References: <88733235@bb.ipt.ru> <200906151009.19181.mel.flynn%2Bfbsd.ports@mailing.thruhere.net> <4A37BB97.8080405@bsdforen.de> <200906161101.22167.mel.flynn%2Bfbsd.ports@mailing.thruhere.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Mel Flynn wrote: > 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? Yes I do. Virus scanners and personal firewalls have proven to be security hazards in the past. Any kind of monitoring is as likely to be a gateway to be exploited, especially considering that monitoring software normally has a lot of privileges. > Also, a library with a vulnerability does not always constitute an exploitable > library for the way a running vital application uses it. Do you have a convincing example? None comes to my mind. > 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". Provide an example where it make sense to keep a vulnerable library around and I will add the option to preserve libraries. >>>> 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? Because you want to download them again if they have been rebuilt without a version change. Something that actually seems to be happening on pointyhead. > >> 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. I've never had this case. I've got the impression that pointyhead rebuilds all dependencies. > >> 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. We've got a PR for this kind of thing around (actually we only request hashes for the INDEX, one step at a time), but I doubt someone is interested in providing this feature. Maybe one day I'll create patches for pointyhead myself, but not before I have done everything that I want to do with pkg_upgrade. There's still so much to be done, it does not yet seem worthwile to invest time into getting to know some else's code, patching it and complaining long enough to get the patches committed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A382604.9090206>