Re: [gentoo-dev] Google Summer of Code 2007
Roy Marples wrote: Saying that, the project is almost complete - the only reason it never hit portage was the it destroyed config parts that it did not know about. After SOC finished, my student has been mute to my emails :/ Thanks Roy Maybe we should restrict people we approve to work on projects to existing Gentoo developers or to people with a history of contributions to bugzilla or overlays. This would at least increase the change that they are not here just for the money. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: upstart on gentoo
On Fri, 16 Feb 2007 21:40:03 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: Oh, and a bit of history - at one point, I used djb's supervise as part of the initscripts so that we could do stuff similarly to upstart. When the initscripts were rewritten, we went to bash and had the intention of adding process monitoring and restart eventually - but gentoo was growing so fast that we never really got to do this. baselayout-1.12 tracks how daemons are started per init script via start-stop-daemon calls. We also enforce 1) what is calls is really the daemon and not just a shell script that launches some 2) When `/etc/init.d/foo status` is called it checks to see if all started daemons are still running, if not then it stops itself. baselayout-2 will change this a little so that status will just report the status, and a new command (crashed, isrunning, any other ideas?) will report if it's crashed or not. We also have C bindings for this. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] rfc: upstart on gentoo
On Friday 16 February 2007, William Hubbs wrote: I saw that we have a request for an ebuild for upstart. I am looking it over and looking at the sample jobs that can be downloaded from the site. I think this would be an intresting idea, and I'm curious what others on this list would think about it. it's like any other package, i dont see any reason to treat it specially ... it isnt the only init package in portage -mike pgpYv87SfjNjr.pgp Description: PGP signature
Re: [gentoo-dev] Timezone /etc/conf.d/clock
On Friday 16 February 2007, Daniel Robbins wrote: OK, I did not understand how it was supposed to work. Is there documentation anywhere that explains how it works and why? other than the comment in /etc/conf.d/clock, nope ... the init script will warn you at boot if you still havent set it currently the only consumer is timezone-data, but conf.d/clock was picked so that any other relevant packages could leverage it -mike pgpp3UBgfgFPh.pgp Description: PGP signature
Re: [gentoo-dev] Google Summer of Code 2007
Petteri Räty wrote: Roy Marples wrote: Saying that, the project is almost complete - the only reason it never hit portage was the it destroyed config parts that it did not know about. After SOC finished, my student has been mute to my emails :/ Thanks Roy Maybe we should restrict people we approve to work on projects to existing Gentoo developers or to people with a history of contributions to bugzilla or overlays. This would at least increase the change that they are not here just for the money. Regards, Petteri Wouldn't that just be discrimination ? :) We did even see Pioto (and killerX soon) become a dev. It's just a guess tho, but i think we could miss opportunities if we do that. Regards, diox -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Google Summer of Code 2007
Ciaran McCreesh wrote: * devmanual. Not converting it over to a new shiny XML thing or whatever, but just extending and reworking the parts that need it. Last year's SoC FAQ said that the actual work would have to be coding, not writing documentation. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] rfc: upstart on gentoo
William Hubbs wrote: All, I saw that we have a request for an ebuild for upstart. I had requests for other highly experimental yet to be tested programs... I think this would be an intresting idea, and I'm curious what others on this list would think about it. As long as it won't touch me I'd be fine, I'm a bit against anything overly complex solutions w/out a good reason (as in: everything you should do with upstart you can do with the current framework...). Even more against them if they look like known wrong ones. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Google Summer of Code 2007
On Sat, Feb 17, 2007 at 12:19:04PM +, Dimitry Bradt wrote: Petteri Räty wrote: Maybe we should restrict people we approve to work on projects to existing Gentoo developers or to people with a history of contributions to bugzilla or overlays. This would at least increase the change that they are not here just for the money. Regards, Petteri Wouldn't that just be discrimination ? :) We did even see Pioto (and killerX soon) become a dev. It's just a guess tho, but i think we could miss opportunities if we do that. Additionally, the purpose of SoC is to bring new people *into* foss, to expose new blood to open source development. Goes without saying, choosing only from folk that *already* are doing opensource kind of defeats that purpose. And, while I don't mean to pick on the involved devs, a good chunk of their projects never really achieved what I'd view as completion- namely, usage of the code, integration, etc. Shit happens admittedly, but devs != guranteed actual 'completion', usage/integration of the code. If you're after ensuring a benefit to gentoo, bluntly, plan better. Ensure that there are sane, public and redundant builtins to the process to ensure work is proceeding. Ensure there is a plan *after completion* for how to integrate the code in, even if the person dissappears. Not will do xyz after completion, actual plan with fallbacks, with part of the SoC completion agreement actually ensuring things are kicked off. Well aware the student writes out their own proposal, but the gentoo can *suggest* things to the student about what they're after, including spelling out whats not likely to be accepted. Doubt folks will like it, but I'd personally try damn hard to ensure there are two active mentors actively watching each person (not just having a fallback mentor); reasoning is simple, redundancy and ensuring that it's a bit harder for two people to be blind to potential issues, whether technical or personal. Upshot is that it's minimal two folks the student is involved with- tend to think the more folks they're involved with, the more likely they are to stick around (assuming they have any interest). Personally, and I admit this is something of an experiment, I'd try to ensure the second is someone somewhat outside the target area. While getting the student chatting with folk (becoming part of the community) is good, someone outside that circle just watching the work/effort can be a fair bit more objective about the state of things. One alternative is trying to structure it such that the students are directly involved with -dev ml on a regular basis; status reports perhaps, although I'd still try to get two people actively watching/interacting with the student. Kindly keep in mind that status reports don't actually mean things are going smoothly either, just is a measure to try and keep as many people watching things as possible. Please keep in mind also, that the suggestions above are intended to try and ensure successful completion, with actual usage of the project (not just generating code that then rots). Might sound distrustful of the student, but that's not the intention- google is effectively investing in gentoo, my suggestions are aimed at ensuring the investment 'pays off' essentially. ~harring pgp8bN3yFFwxO.pgp Description: PGP signature
[gentoo-dev] Last rites for media-fonts/mikachan-font
As per summary, I've just masked mikachan-font for removal. Don't panic! I'm not removing the mikachan font from portage. This package installs, depending on version, either a TTF font (TrueType Fonts files) or a TTC font (TrueType Collection); the latter is not compatible with some software, like GD if I remember correctly, that expects only TTF fonts. To get around this problem, mikachan is now split in three packages, each of which installs the same fonts in a different format: media-fonts/mikachan-font-otf OpenType Fonts media-fonts/mikachan-font-ttf TrueType Fonts media-fonts/mikachan-font-ttc TrueType Collection this way you can have fine grained selection of fonts to install. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgp4Rpyq2lIaZ.pgp Description: PGP signature
[gentoo-dev] the destiny of the 2.4 headers
now that the 2.6 headers have entered a sane state and are *quite* nice to work with, i have no inclination whatsoever to touch unsanitized headers (keep your puns to yourself :p) so here's the question i pose: what to do ? people file bug reports saying package FOO fails to build with linux-2.4.xx headers ... my answer is well, that sucks, but package FOO is not going to be changed as it builds correctly with sanitized linux-2.6.xx headers do we want to try and maintain our own sanitized 2.4 headers ? this would require our own git tree as trying to do development on a patch-based setup is an exercise in insanity ... or perhaps we want to unmask the sanitized 2.6 headers for use on a 2.4 profile ? the core ramifications: beneficial actually; we tell glibc what the min kernel version it needs to run on (2.4.1 currently), and it will enable all features required between that and whatever kernel version your headers are ... so if you were to upgrade your kernel, glibc would automatically take advantage of the newer system calls -mike pgpyF3wWkM4qZ.pgp Description: PGP signature
Re: [gentoo-dev] the destiny of the 2.4 headers
Mike Frysinger wrote: now that the 2.6 headers have entered a sane state and are *quite* nice to I'm looking forward to see the cvs log of the removal of 2.4 lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] the destiny of the 2.4 headers
Mike, I think you have a good plan. Retiring the 2.4 headers sounds like the right thing to do. Building glibc against 2.6 and enabling backwards compatibility with older kernels should not be problematic. It all sounds good from a maintainability and stability perspective. Nothing should break in theory, but of course in this line of work there is no guarantee that there won't be unexpected transition problems for real users on real systems - but you know that already. With some reasonable amount of testing I think it is a great idea. -Daniel On 2/17/07, Mike Frysinger [EMAIL PROTECTED] wrote: now that the 2.6 headers have entered a sane state and are *quite* nice to work with, i have no inclination whatsoever to touch unsanitized headers (keep your puns to yourself :p) so here's the question i pose: what to do ? people file bug reports saying package FOO fails to build with linux-2.4.xx headers ... my answer is well, that sucks, but package FOO is not going to be changed as it builds correctly with sanitized linux-2.6.xx headers do we want to try and maintain our own sanitized 2.4 headers ? this would require our own git tree as trying to do development on a patch-based setup is an exercise in insanity ... or perhaps we want to unmask the sanitized 2.6 headers for use on a 2.4 profile ? the core ramifications: beneficial actually; we tell glibc what the min kernel version it needs to run on (2.4.1 currently), and it will enable all features required between that and whatever kernel version your headers are ... so if you were to upgrade your kernel, glibc would automatically take advantage of the newer system calls -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [RFC] mask and force various profile specific USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, If we mask and force various profile specific USE flags appropriately, it will give repoman the information it needs to stop producing bogus warnings about unsatisfied conditional dependencies that are actually irrelevant. An additional benefit is that emerge - --newuse will ignore the addition or removal of these flags from IUSE (since masked/forced flags do not represent choices for the user). In order to do this, selected profile specific flags should be masked in the base profile and unmasked/forced in the specific profiles which they apply to. The unmasking is necessary because use.mask currently overrides use.force. USE flags suggested as candidates for masking/forcing include all USE_EXPAND flags derived from the USERLAND, KERNEL, and ELIBC variables. We can make this change to the profiles immediately because use.mask support has been available for a long time, and use.force is simply ignored by older versions of portage. Thoughts? Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) iD8DBQFF1445/ejvha5XGaMRAqr1AKDy0M1EUbrQWsWD+iMRKIUhtvyteQCfUt14 qXAgR8+pR/y5mtu5EUm5U10= =geAX -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-portage-dev] dep resolution weirdness
Hi guys. I am quite confused by the following: aldar ~ # emerge -puD world --tree These are the packages that would be merged, in reverse order: Calculating world dependencies... done! [nomerge ] dev-ada/cbind-6.0 [nomerge ] virtual/gnat-4.1 [ebuild UD] dev-lang/gnat-gcc-4.1.1 [4.1.2] aldar ~ # emerge -puD cbind --tree These are the packages that would be merged, in reverse order: Calculating dependencies... done! (or, for that matter: aldar gnat # e -puD virtual/gnat These are the packages that would be merged, in order: Calculating dependencies... done! ) Here, cbind is an Ada library that needs gnat - the Ada compiler, so it DEPENDs (and RDEPENDs) on a virtual which provides the choice of gnat-gcc or gnat-gpl compiler(s). These can be installed side by side (using toolchain-like eclass to manage location and eselect module for choosing the active one) whence the virtual. The relevant dependency lines are here: dev-ada/cbind: DEPEND=virtual/gnat virtual/gnat-4.1: RDEPEND==dev-lang/gnat-gcc-4.1* DEPEND= (and virtual/gnat-3.4: RDEPEND=|| ( =dev-lang/gnat-gcc-3.4* =dev-lang/gnat-gpl-3.4* ) DEPEND= although it looks like this one is not considered in this particular case) As you see emerge -uD world wants to downgrade gnat for some reason (which is wrong), while emerge -uD cbind (or any other Ada library that has similar dependencies) does not (which is right). So, what is going on here? Is this a problem with specifying dependencies? If so, how should I fix this? Is this a portage bug? A stale cache? I would like to get this fixed or worked around in some way apparently :). (I just issued an update to gnat-gcc and hit this. Oh, and ~dev-lang/gnat-gcc-4.1 as RDEPEND in virtual/gnat does not work at all (just, as I understand, it should not)). George -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] dep resolution weirdness
On Sat, 17 Feb 2007 12:30:31 +0100 George Shapovalov [EMAIL PROTECTED] wrote: Hi guys. I am quite confused by the following: aldar ~ # emerge -puD world --tree These are the packages that would be merged, in reverse order: Calculating world dependencies... done! [nomerge ] dev-ada/cbind-6.0 [nomerge ] virtual/gnat-4.1 [ebuild UD] dev-lang/gnat-gcc-4.1.1 [4.1.2] aldar ~ # emerge -puD cbind --tree These are the packages that would be merged, in reverse order: Calculating dependencies... done! (or, for that matter: aldar gnat # e -puD virtual/gnat These are the packages that would be merged, in order: Calculating dependencies... done! The relevant dependency lines are here: dev-ada/cbind: DEPEND=virtual/gnat virtual/gnat-4.1: RDEPEND==dev-lang/gnat-gcc-4.1* DEPEND= (and virtual/gnat-3.4: RDEPEND=|| ( =dev-lang/gnat-gcc-3.4* =dev-lang/gnat-gpl-3.4* ) DEPEND= although it looks like this one is not considered in this particular case) As you see emerge -uD world wants to downgrade gnat for some reason (which is wrong), while emerge -uD cbind (or any other Ada library that has similar dependencies) does not (which is right). Is there maybe a different package in world that depends on =gnat-gcc-4.1.1? Anyway, you may want to look at --debug output to get a clue why it wants to downgrade. Oh, and ~dev-lang/gnat-gcc-4.1 as RDEPEND in virtual/gnat does not work at all (just, as I understand, it should not)). It should work, but it's not the same as the dep you stated above: it would match gnat-gcc-4.1-r1, gnat-gcc-4.1-r2 and so on, but not gnat-gcc-4.1.1, gnat-gcc-4.1.2, ... Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-portage-dev] New preserve-libs feature
If you haven't noticed, I just added a new 'preserve-libs' feature for bug 62207 that moves shared object that are still used but would be removed on an update into the new package instance (so on a update from expat-1 to expat-2 the user would still have libexpat.so.0, owned by expat-2). The actual match criteria are a bit stricter, but you get the idea. I think this is an long overdue bugfix, but given past discussions not everyone has the same opinion, though the last discussion about it ended without a conclusion (at least none that I could see). So everyone who has valid objections to the _general idea_ of this implementation (preserving old libraries to avoid some runtime linker errors) speak up now. Just keep the following things in mind: - I'm not claiming that it's a silver bullet to all possible runtime linker problems, it's supposed to cover some of the common cases (like the expat problem) - I'm not claiming that the implementation is perfect yet - This feature is currently optional, so I'm not forcing it down on anyone (in fact it's completely hidden for now). Of course if people start using it ebuild devs will have to deal with it sooner or later, but lets discuss it here first. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] dep resolution weirdness
On Sat, 17 Feb 2007 13:42:49 +0100 George Shapovalov [EMAIL PROTECTED] wrote: Ok, found it. Thanks Marius! (for the debug hint) It was indeed forcing gnat-gcc-4.1.1 by asis-gcc-4.1.1 which has =dev-lang/gnat-4.1.1 (this is an extension to compiler and has to match it 1 for 1, forgot to bump that one :(). However, shouldn't --tree have reported the relevant package as requiring this downgrade instead of some other, pretty much arbitrary (from dependants of gnat-gcc)? In an ideal world: yes, but portage is far from being ideal (I won't pretend to know the internals of the dep resolver, so can't give a good explanation for this behavior). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] New preserve-libs feature
Marius Mauch wrote: So everyone who has valid objections to the _general idea_ of this implementation (preserving old libraries to avoid some runtime linker errors) speak up now. For how long are these libraries preserved? This might have a security impact in cases like the recent openssl-case where you had to upgrade to an incompatible ABI because the version using the old one was vulnerable. Using preserve-libs it would leave the old lib around, making it possible for programs to link against the wrong version and ending up being vulnerable. I realize that the feature is meant to help the transitional phase until all apps are built against the new ABI, but how would you find these vulnerable apps currently? revdep-rebuild wouldn't rebuild them since they are still functional. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] New preserve-libs feature
On Saturday 17 February 2007, Simon Stelling wrote: Using preserve-libs it would leave the old lib around, making it possible for programs to link against the wrong version and ending up being vulnerable. generally, this is incorrect the only way you could link against it is if you were to actually specify the full path to the library: ... /usr/lib/libfoo.so.3 ... and since that's invalid usage, there is no real security impact -mike pgpBnvQvPKu3N.pgp Description: PGP signature
Re: [gentoo-portage-dev] New preserve-libs feature
On Sat, 17 Feb 2007 14:55:26 +0100 Simon Stelling [EMAIL PROTECTED] wrote: Marius Mauch wrote: So everyone who has valid objections to the _general idea_ of this implementation (preserving old libraries to avoid some runtime linker errors) speak up now. For how long are these libraries preserved? This might have a security impact in cases like the recent openssl-case where you had to upgrade to an incompatible ABI because the version using the old one was vulnerable. Using preserve-libs it would leave the old lib around, making it possible for programs to link against the wrong version and ending up being vulnerable. I realize that the feature is meant to help the transitional phase until all apps are built against the new ABI, but how would you find these vulnerable apps currently? revdep-rebuild wouldn't rebuild them since they are still functional. Currently they are around as long as they are referenced by other packages or until the package is unmerged. And yes, there should be a way to tell revdep-rebuild/the user which packages should/need to be rebuilt, but I haven't made my mind up yet on how to accomplish that (in fact atm there is no separation between native and imported libs in vdb, I'm aware that needs to be added). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-portage-dev] Re: r5975 - FEATURES=preserve-libs
Realize you didn't want comments upon the implementation, but tough
cookies, already reviewed it; suckers in svn mainline anyways, thus
it's fair game.
Modified: main/trunk/pym/portage/dbapi/vartree.py
===
--- main/trunk/pym/portage/dbapi/vartree.py 2007-02-17 04:17:14 UTC (rev
5974)
+++ main/trunk/pym/portage/dbapi/vartree.py 2007-02-17 08:53:35 UTC (rev
5975)
@@ -523,6 +523,39 @@
write_atomic(cpath, str(counter))
return counter
+ def get_library_map(self):
+ Read the global library-consumer map for this vdb instance
+ mapfilename = self.getpath(.NEEDED)
+ if not os.path.exists(mapfilename):
+ self.update_library_map()
+ rValue = {}
+ for l in open(mapfilename, r).read().split(\n):
for l in open(mapfilename):...
# no point in building the list in memory when you're just itering.
+ mysplit = l.split()
+ if len(mysplit) 1:
+ rValue[mysplit[0]] = mysplit[1].split(,)
# testing for this is stupid; your update code doesn't write
# empty entries, nor should it be allowed in the file.
rValue[myvalue[0]] = mysplit[1].split(',')
+ return rValue
+
+ def update_library_map(self):
+ Update the global library-consumer map for this vdb
instance.
+ mapfilename = self.getpath(.NEEDED)
+ obj_dict = {}
+ for cpv in self.cpv_all():
+ needed_list = self.aux_get(cpv, [NEEDED])[0]
+ for l in needed_list.split(\n):
+ mysplit = l.split()
+ if len(mysplit) 2:
+ continue
+ libs = mysplit[1].split(,)
+ for lib in libs:
+ if not obj_dict.has_key(lib):
# __contains__ is your friend.
# has_key is the slower, slightly retarded older brother.
# avoid the older brother.
if lib in obj_dict:
...
+ obj_dict[lib] = [mysplit[0]]
+ else:
+ obj_dict[lib].append(mysplit[0])
# alternative, conciser form.
obj_dict.setdefault(lib, []).append(mysplit[0])
+ mapfile = open(mapfilename, w)
+ for lib in obj_dict.keys():
+ mapfile.write(lib+ +,.join(obj_dict[lib])+\n)
# per the norm, stop using keys(). You're not mutating the dict, thus
# no reason to for list creation unless you *want* to make portage
# slower then it is already.
# use iteritems further, instead of forcing a lookup for every single
# item when you're already itering the dict.
for lib, revs in obj_dict.iteritems():
mapfile.write(%s %s\n % (lib, ','.join(revs)))
+ mapfile.close()
+
class vartree(object):
this tree will scan a var/db/pkg database located at root (passed to
init)
def __init__(self, root=/, virtual=None, clone=None, categories=None,
@@ -952,6 +985,9 @@
doebuild(myebuildpath, cleanrm, self.myroot,
self.settings,
tree=vartree,
mydbapi=self.vartree.dbapi,
vartree=self.vartree)
+
+ # regenerate reverse NEEDED map
+ self.vartree.dbapi.update_library_map()
finally:
if builddir_lock:
@@ -1162,6 +1198,7 @@
This function does the following:
+ Preserve old libraries that are still used.
Collision Protection.
calls doebuild(mydo=pkg_preinst)
Merges the package to the livefs
@@ -1197,6 +1234,10 @@
if not os.path.exists(self.dbcatdir):
os.makedirs(self.dbcatdir)
+ myfilelist = listdir(srcroot, recursive=1, filesonly=1,
followSymlinks=True)
+ mysymlinks = filter(os.path.islink, listdir(srcroot,
recursive=1, filesonly=0, followSymlinks=False))
+ myfilelist.extend(mysymlinks)
+
# I hope this feature is really worth it, since previously, the
# two walks of ${D} occured only if FEATURES=collision-protect.
# via this change, even if FEATURES=-collision-protect -preserve-libs,
# the user now gets to enjoy the two additional walks.
#
# low mem system with large ${D}, just jacked up the runtime a fair
# bit via that regression.
#
otherversions = []
for v in self.vartree.dbapi.cp_list(self.mysplit[0]):
otherversions.append(v.split(/)[1])
@@ -1209,17 +1250,59 @@
catsplit(slot_matches[0])[1], destroot,
Re: [gentoo-portage-dev] New preserve-libs feature
On Sat, Feb 17, 2007 at 09:39:58AM -0500, Mike Frysinger wrote: On Saturday 17 February 2007, Brian Harring wrote: Security impact is from a pkg potentially dragging along old libs; if you've got a stable pkg that gets an update once every blue moon, it can hold onto the lib for a *long* time while still using the lib; thus if a vuln. in the lib, said pkg still is screwed. umm, no ... the package itself is updated against the new copy while the old copy exists for other packages that have already been built Suspect you're ignoring soname changes, which is about all this patch would address- for example, ssl's old form of breakage. In that case, *yes* the package gets updated, anything recompiled should get the correct lib (assuming the code knows the appropriate linker args), but the old vuln. lib still will hang around as long as anything refs it. Other angle is someone intentionally forcing usage of a known bad library that is still dangling. Corner case, but doable. as i said, this is the invalid syntax: ... /usr/lib/libfoo.so.3 ... Not to LD_PRELOAD :) Haven't tried anything crazy, but suspect it can be abused to override to the old. Bit curious how this is going to behave if via linked in libs, new loc and old get loaded alongside... this would require multiple libraries to be involved in the equation and the answer is undefined behavior which most certainly result in runtime failures ... Point there was that instead of just bailing with lib is missing, suspect it'll manage to run, then segfault at potentially crappy times. ~harring pgpTux6lyn48U.pgp Description: PGP signature
Re: [gentoo-portage-dev] New preserve-libs feature
On Saturday 17 February 2007, Brian Harring wrote: On Sat, Feb 17, 2007 at 09:39:58AM -0500, Mike Frysinger wrote: On Saturday 17 February 2007, Brian Harring wrote: Security impact is from a pkg potentially dragging along old libs; if you've got a stable pkg that gets an update once every blue moon, it can hold onto the lib for a *long* time while still using the lib; thus if a vuln. in the lib, said pkg still is screwed. umm, no ... the package itself is updated against the new copy while the old copy exists for other packages that have already been built Suspect you're ignoring soname changes, which is about all this patch would address- for example, ssl's old form of breakage. In that case, *yes* the package gets updated, anything recompiled should get the correct lib i'm not ignoring soname changes, those are exactly what i'm talking about (assuming the code knows the appropriate linker args) there is no such thing ... it's always -lfoo the old vuln. lib still will hang around as long as anything refs it. of course and this is the desired behavior ... people need to run revdep-rebuild, there's no two ways about it Other angle is someone intentionally forcing usage of a known bad library that is still dangling. Corner case, but doable. as i said, this is the invalid syntax: ... /usr/lib/libfoo.so.3 ... Not to LD_PRELOAD :) Haven't tried anything crazy, but suspect it can be abused to override to the old. again, not in any scenario that actually matters ... so this too is a pointless line of thought to pursue as it has no real security impact Bit curious how this is going to behave if via linked in libs, new loc and old get loaded alongside... this would require multiple libraries to be involved in the equation and the answer is undefined behavior which most certainly result in runtime failures ... Point there was that instead of just bailing with lib is missing, suspect it'll manage to run, then segfault at potentially crappy times. this is really an outside case and not worth worrying over -mike pgpaUyoVR2L1f.pgp Description: PGP signature
Re: [gentoo-portage-dev] New preserve-libs feature
On Sat, Feb 17, 2007 at 10:09:35AM -0500, Mike Frysinger wrote: On Saturday 17 February 2007, Brian Harring wrote: On Sat, Feb 17, 2007 at 09:39:58AM -0500, Mike Frysinger wrote: On Saturday 17 February 2007, Brian Harring wrote: Security impact is from a pkg potentially dragging along old libs; if you've got a stable pkg that gets an update once every blue moon, it can hold onto the lib for a *long* time while still using the lib; thus if a vuln. in the lib, said pkg still is screwed. umm, no ... the package itself is updated against the new copy while the old copy exists for other packages that have already been built Suspect you're ignoring soname changes, which is about all this patch would address- for example, ssl's old form of breakage. In that case, *yes* the package gets updated, anything recompiled should get the correct lib i'm not ignoring soname changes, those are exactly what i'm talking about (assuming the code knows the appropriate linker args) there is no such thing ... it's always -lfoo The point is that it is *not* always -lfoo. Commenting about packages that collapse, split libs apart, where -lorig becomes -lnew1 -lnew2. Non-slotted package upgrade crossing a major version (assuming they're not being dumb asses), that scenario *does* occur, and it's not the same args. Until all packages are upgraded (assuming an ugprade is available) to use the new layout, the old lingers. Also, so help me, if you respond to valid critism with it doesn't actually matter as a retort, you're getting wedgied considering this is one of the scenarios this patch is supposed to address :p Other angle is someone intentionally forcing usage of a known bad library that is still dangling. Corner case, but doable. as i said, this is the invalid syntax: ... /usr/lib/libfoo.so.3 ... Not to LD_PRELOAD :) Haven't tried anything crazy, but suspect it can be abused to override to the old. again, not in any scenario that actually matters ... so this too is a pointless line of thought to pursue as it has no real security impact Eh? setuid comes to mind, or any other attempt to finagle privs via forcing the bad lib. Combined with the scenario above (where a crappy pkg can hold the lib around for a *long* time), tend to think it matters. Bit curious how this is going to behave if via linked in libs, new loc and old get loaded alongside... this would require multiple libraries to be involved in the equation and the answer is undefined behavior which most certainly result in runtime failures ... Point there was that instead of just bailing with lib is missing, suspect it'll manage to run, then segfault at potentially crappy times. this is really an outside case and not worth worrying over It's a change in behaviour; previously, would just flat out stop; now it'll run, but probably take a poo in your shoes. Going from the potential of it won't run to it eats itself in special way is *not* something I'd blistfully write off as not worth worring over, considering what this change intends to address. Additional comment, introducing the change makes it so that glsa's aren't really as accurate- version based, rather then lib. ~harring pgp91Hw929egi.pgp Description: PGP signature
Re: [gentoo-portage-dev] New preserve-libs feature
On Saturday 17 February 2007, Brian Harring wrote: On Sat, Feb 17, 2007 at 10:09:35AM -0500, Mike Frysinger wrote: On Saturday 17 February 2007, Brian Harring wrote: (assuming the code knows the appropriate linker args) there is no such thing ... it's always -lfoo The point is that it is *not* always -lfoo. Commenting about packages that collapse, split libs apart, where -lorig becomes -lnew1 -lnew2. so why is this an issue ... the build system for a package either takes it into account or it doesnt, it'll behave exactly the same whether we preserve the ABI lib we're preserving runtime libs here, not ones detectable by a linker process and thus a build system Also, so help me, if you respond to valid critism with it doesn't actually matter as a retort, you're getting wedgied considering this is one of the scenarios this patch is supposed to address :p i guess come up with a valid criticism first and then i wont use that Eh? setuid comes to mind why ? pretty much all LD_* variables are filtered by ldso in a set*id environment or any other attempt to finagle privs via forcing the bad lib. considering the only privs you can finagle are your own, this is not an issue Combined with the scenario above (where a crappy pkg can hold the lib around for a *long* time), tend to think it matters. it doesnt It's a change in behaviour; previously, would just flat out stop; now it'll run, but probably take a poo in your shoes. Going from the potential of it won't run to it eats itself in special way is *not* something I'd blistfully write off as not worth worring over, considering what this change intends to address. let's review the original by copy paste: - I'm not claiming that it's a silver bullet to all possible runtime linker problems, it's supposed to cover some of the common cases (like the expat problem) what you're talking about can never be fully solved by the methodology utilized here ... if you want the full solution, go implement your own behavior Additional comment, introducing the change makes it so that glsa's aren't really as accurate- version based, rather then lib. considering current glsa integration (== 0), i'd say proper general infrastructure needs to be put into place first -mike pgp0OkDNaKm9o.pgp Description: PGP signature
