Tux news - Linux ubuntu fedora gentoo gnome news

Gentoo (5 unread)

Planet Gentoo

Diego Pettenò: PAM authentication for paranoids

Posted: January 5th, 2009, 12:28pm CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pBefore I resume working on span class=capsPAM/span (I need to implement a change to pam_lastlog to fix a href=https://bugs.gentoo.org/show_bug.cgi?id=244816a pernicious bug/a), I wanted to just write a quick entry for the paranoid of you who still use span class=capsPAM/span for system login./p pSince, as you most likely already know, a href=http://www.win.tue.nl/hashclash/rogue-ca/span class=capsMD5/span is once again considered insecure/a, one obvious concern would be the fact that passwords saved in span class=capsMD5/span on a system are not secure either. For this reason if you’re using Linux-PAM, you can make use of the span class=capsSHA512/span hashing of system password keys, which a href=http://blog.flameeyes.eu/2008/08/05/pam-delays-and-hashesI already wrote about/a./p pRemember that to use that you have to make sure your Linux-PAM (sys-libs/pam) is built against a recent enough version of glibc. Unfortunately the version of pambase with this feature hasn’t hit stable yet, the bug above is blocking it, and I’m going to have to hack at pam_lastlog to fix that./p pWhat I didn’t write last time, is that you can easily spot if your system is using md5 passwords by using this simple command from root:/p div class=typocodeprecode class=typocode_default # fgrep '$1$' /etc/shadow/code/pre/div pOf course one has to access your code/etc/shadow/code file to breach your passwords, so your system has to have been compromised before, but it’s still not nice if they can find out what your basic passwords are./p pMoving on./p /div
Diego Pettenò: For A Parallel World. Case Study n.5: parallel install

Posted: January 3rd, 2009, 9:01pm CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pAfter a longish time, here for you a new chapter of my widely read series a href=http://blog.flameeyes.eu/tag/foraparallelworldFor A Parallel World/a, improving buildsystems to reduce build time on modern multiprocessor, multicore systems./p pThis time, rather than the usual build failures, I’m going to speak of a parallel install failure. Even though one can think of install as a task that rarely can fall into problems like race conditions and the such, and even though it’s probably the part that gets less boost when using parallel make on a multicore system (since it’s usually I/O bound rather than span class=capsCPU/span bound), it’s actually one very fragile part of many packages./p pOne of the common failures is due to old codeinstall-sh/code script used to simulate the codeinstall/code command on systems too old to have a span class=capsPOSIX/span-compatible one, and which is also used to create directories recursively if codemkdir -p/code is missing. For a series of reason, this hits pretty often on FreeBSD, but this is beside the point. This can be easily solved by replacing the old faulty script with an updated copy out of automake or libtool, which does not have problems at all./p pA few times, the problem is instead due to a broken codeMakefile.am/code. Let’s take a practical example from some software I fixed recently after being called in action by nixnut: a href=https://bugs.gentoo.org/show_bug.cgi?id=249165gramps/a . Please note that if you look at the bug now you’re going to spoil the post, since it contains the solution straight away, while I’m going to explain it step by step./p pLet’s start from the reported build log:/p div class=typocodeprecode class=typocode_default test -z /usr/share/gramps/docgen || /bin/mkdir -p /var/tmp/portage/app-misc/gramps-3.0.3/image//usr/share/gramps/docgen /usr/bin/install -c -m 644 'gtkprintpreview.glade' '/var/tmp/portage/app-misc/gramps-3.0.3/image//usr/share/gramps/docgen/gtkprintpreview.glade' /usr/bin/install -c -m 644 'gtkprintpreview.glade' '/var/tmp/portage/app-misc/gramps-3.0.3/image//usr/share/gramps/docgen/gtkprintpreview.glade' /usr/bin/install: cannot create regular file `/var/tmp/portage/app-misc/gramps-3.0.3/image//usr/share/gramps/docgen/gtkprintpreview.glade': File exists make[3]: *** [install-docgenDATA] Error 1 make[3]: *** Waiting for unfinished jobs..../code/pre/div pAs usual, the first thing we’re looking for when there is a parallel build (or install) failure are repeated commands. As I’ve shown in a href=http://blog.flameeyes.eu/2008/08/29/for-a-parallel-world-case-study-n-2-misknowing-your-make-rulesCase Study n. 2/a, when the same command is repeated multiple times it’s often due to mistakes in the Makefiles, thus before thinking of a problem with the dependencies, I check for that. It’s way more common especially on automake-based build systems./p pSo indeed we can see there are two calls to the codeinstall/code command for the file codegtkprintpreview.glade/code (this also shows us that it’s not a problem of old and faulty install-sh script since the call is directly to the system command). Contrary to what happens when it’s a build rule that is wrongly expressed in the makefile, the double-call during install phase is usually present both using parallel jobs and not. The difference is that when the two calls happen sequentially, the second just overwrites the results of the first; wastes time but it’s successful. On the other hand when parallel jobs are used, the two calls are often enough happening at the same time, and thus we have a race condition./p pOkay so next step as usual is to look at the incriminated Makefile.am:/p div class=typocodeprecode class=typocode_default [snip] docgen_DATA = \ gtkprintpreview.glade dist_docgen_DATA = $(docgen_DATA) [snip]/code/pre/div pHere we’re at the core of the problem. The codegtkprintpreview.glade/code file is part of the sources, and it has to be installed as part of the codedocgen/code class of files (thus in code$docgendir/code). But the data installed in that path is listed twice, once in the codedocgen_DATA/code variable and one in codedist_docgen_DATA/code, causing the file to be installed twice on two independent targets. Since the two targets are independent, when using parallel jobs they both will run at the same time the same command./p pLet me try to explain what the mistake has been. By default the sources are packaged up in the final tarball, if they are not generated by rules from the make process; sometimes you wish files that are built by make to still be distributed, and thus you either have to use codeEXTRA_DIST/code or prefix codedist_/code to the class of the installed files, to explicit that the files have to be distributed. Unfortunately the gramps developers didn’t know automake well enough, and thought that codedist_docgen_DATA/code worked quite a lot like codeEXTRA_DIST/code (maybe it actually used codeEXTRA_DIST/code in the past, for what I know), and thus duplicated the variable content./p pThe solution? Just replace the use of codedocgen_DATA/code with codedist_docgen_DATA/code and remove the second definition, the problem is solved at the source./p /div
Tobias Klausmann: A tale of too many parameters

Posted: January 3rd, 2009, 3:12pm CET by Tobias Klausmann (klausman)

pWith 2.6.28 came ext4, which I've been using on several not-so-important filesystems for a while now. Also, I had switched the root file system on my laptop to non-encrypted quite a few months ago. I do recognize the problem of stolen laptops and had started running an encrypted rootfs years ago, but I lent my laptop to my flatmate and didn't want to bother her with the whole cryptfs thing. Anyway, I thought I'd kill two birds with one stone and switch back to ext4 on a crypted volume. Shouldn't be all that hard, right?/p pThe first problem I ran into is that very few live CDs support ext4. No matter, I can mount a backup disk and the laptops disk in my amd64 workstation, copy stuff around, not that hard. I also made sure I had an ext4-capable 2.6.28 on the laptop. So I copied the stuff to a spare disk, created the crypto volume, made a filesystem, copied everything back and re-activated the initrd script for cryptofs. Put the disk back into the laptop and… it didn't work./p pcryptsetup told me that there was no slot available with the passphrase I had entered. Had I mistyped something? Ok, back to the amd64 workstation. Hm. The config of the kernel looks ok, all the cryptmodules are there. So I replaced all the binaries with those from laptop installation (the passphrase I used wasn't wrong). I figured that maybe I did something wrong with the kernel after all and decided to rebuild it from scratch. But I can't build a 32-bit kernel on the amd64 machine because it's a pure 64-bit installation there[1]./p pFortunately, my router/fileserver is a PIII so it can build a kernel for my Pentium-M laptop. Also, it already has a cryptofs-aware kernel. I mounted everything as needed, chrooted into the filesystem and started rebuilding the kernel. But at the very end of the kernel build, there's a call to awk which resulted in a SIGILL. Ok, so then I changed out of the chroot, did a make mrproper and proceeded to build the kernel with the fileserver's toolchain. That went well and I also copied over a different version of cryptsetup to try out./p pUsing the new kernel (and cryptsetup), I istill/i had no joy. I even added strace and sundry other programs to the initrd (which was getting cramped). I saw crypsetup open the device, read the first few blocks and then decide it didn't like it. Was cyptsetup arch-aware? I couldn't imagine that the on-disk format depended on the arch used to make the cryptodev and filesystems[2]. That couldn't be the problem since I could read the filesystem on both my amd64 and the PIII fileserver./p p Had I manipulated the wrong kernel all the time? I renamed the kernel image on-disk (to vmlinuz-2.6.28a) and changed the grub config to call the new kernel. Upon boot, I used grubs edit command and sure enough, the new kernel name. So the grub.conf was used as it should be, what about the kernel? I booted the renamed kernel and istill/i cryptsetup refused to open the filesystem./p pIn desparation, I decided to build an dynamically linked cryptsetup, hoping that some code blob was missing and the linking infrastructure would do a better job of telling me iwhat/i was missing./p pSuccess at last, I could open the cryptodev with the correct passphrase! Apparently, something in the interface between cryptsetup and the kernel changed with 2.6.28 and neither of them thought it fit to tell me in an understandable way. Interestingly, the fileserver never showed any of this behaviour (and yes, I switched to 2.6.28 there a while ago)./p pHome free? Not really. The kernel refused to mount the rootfs since it wanted CONFIG_LSF to be set (that's Large Single File support). Ok, so I rebuilt the kernel iagain/i. No joy. I was getting a tad annoyed by this point. Fortunately, I took the time to make some tea and when I was staring at the tea infusing, it hit me: had I copied the new LSF-aware kernel to the changed name in grub.conf (vmlinuz-2.6.28a)? No, I hadn't. Fixed that and finally everything worked./p pNow you've read this post over the course of maybe a few minutes. Keep in mind that for every single change, I had to ipull the disk from the laptop, shutdown the other machine, plug the disk into that machine, boot it, make the change, shut the machine down, put the disk back in the laptop, boot the laptop, doesn't work, repeat. Also, I had to do stuff like fixing typos, do some (ultimately useless) reordering in the initrd, checksumming, etc. In all, I spent several hours trying to fix this simple matter./p pLesson learned: Don't change too many things at the same time or you'll never know which one spit in your soup./p pFootnotes: /p ol liYes, I know, I could have. But it would have been more effort (or at least it seemed that way at the time)./li liStuff like that used to be the case way-back-when. Good riddance./li /ol h2Comments/h2 piKevin Bowling/i writes:/p blockquote pTake a look here for my and another Gentoo user's ext4 experience. a href=http://www.kev009.com/wp/2008/12/how-to-upgrade-to-ext4-in-place/http://www.kev009.com/wp/2008/12/how-to-upgrade-to-ext4-in-place/a/p pMine was fairly painless, but I'm not trying to do encryption (laptop disks are slow enough already!). The other Kevin's was a bit more involved but he is doing crazy encryption stuff like you :-P./p /blockquote piBranko Badrljica/i writes:/p blockquote pI'm deferring having encrypted notebook disks to the moment when it will be possible to do it with GPU, not CPU./p pAs it is now, it taxes CPU quite considerably. This might be acceptable for some apps that are not that CPU intensive, but becomes bottleneck when you decide to stretch that multitasking a bit.../p /blockquote pWell, my laptop isn't the thing I do heavy computing on. Mostly, it's a rather oversized MP3-Player, fallback storage for my digital camera, trusted access point for Internet and fallback machine when my main workstation croaks. As such, I don't mind the impact of cryptofs on the overall performance. In other words: even with a crypted disk, it's fast enough for what I need./p
Diego Pettenò: Free virtualisation - not working yet

Posted: January 3rd, 2009, 3:27am CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pIf you’ve been following my blog for a while you probably remember how much I fought with VirtualBox once it was released to get it to work, so that I could use OpenSolaris. Nowadays, even with some quirks, VirtualBox Open Source Edition is fairly usable, and I’m using it not only for OpenSolaris but also for a Fedora system (which I use for comparing issues with Gentoo), a Windows install (that I use for my job), and a Slackware install that I use for kernel hacking./p pObviously, the problem is that the free version of VirtualBox come with some disadvantages, like not being able to forward span class=capsUSB/span devices, having limited type of hardware to virtualise and so on. This is not much of a problem for my use, but of course it would have been nicer if they just open sourced the whole lot. I guess the most obnoxious problem with VirtualBox (OSE at least, not sure about the proprietary version) is the inability to use a true block device as virtual disk, but rather having to deal with the custom image format that is really slow at times, and needs to pass through the span class=capsVFS/span./p pFor these reasons Luca suggested me many times to try out kvm instead, but I have to say one nice thing of VirtualBox is that it has a quite easy to use interface which allows me to set up new virtual machines in just a few clicks. And since nowadays it also supports VT-x and similar, it’s not so bad at all./p pBut anyway, I wanted to try kvm, and tonight I finally decided to install it, together with the a href=http://virt-manager.et.redhat.com/virt-manager frontend/a although there are lots of hopes for this, it’s not yet good enough, and it really isn’t usable for me at all. I guess I might actually get to hack at it, but maybe this is a bit too soon yet./p pContinue reading on my blog for the reasoning, if you’re interested./p pOne thing I really dislike of the newer versions of VirtualBox is that it went the VMware route and decided to create its own kernel module to handle networking. They said it’s for performance reasons but I’d expect the main reason is that it would allow them to have a single interface between Linux, Windows, Solaris and so on. The span class=capsTUN/span/TAP interface is Linux-specific so supporting that together with whatever they have been doing on the other operating systems is likely a cost for them. Although I can understand their reasoning, it’s not that I like it at all. More kernel code means more code that can crash your system, especially when not using the Open Source Edition./p pInterestingly enough, the RedHat’s Virtual Machine Manager is instead doing its best to avoid creating new network management software, and uses very common pieces of software: dnsmasq as span class=capsDHCP/span server, the Linux kernel bridging support, and so on. This is very good, but it also poses a few problems: first of all, my system already runs a span class=capsDHCP/span server, why do I have to install another? But it’s not just that; instead of creating an userspace networking bridging software, like VirtualBox does, it tries to use what the kernel provides already, in the form of the bridging support and iptables to forward requests and create span class=capsNAT/span zones. This is all fine and dandy, as it reduces the feature duplication in software, but obviously requires more options to be enabled in kernels that might not otherwise have it enabled at all./p pAs it happens, my system does have bridging support installed, but not iptables nor masquerade targets and similar. Up to now I never used them so it had no reason to be there. I also sincerely can’t understand why it does need it if I don’t want a span class=capsNAT/span, but it doesn’t seem to allow me to set up the network myself. Which would include me being able to just tell it to create a new interface and add it to a bridge I manage myself, leaving to me all the details like dhcp, and thus not requiring iptables at all./p pAlso, even though there is a way to configure an span class=capsLVM/span-based storage pool, it does not seem to allow me to choose directly one of the volumes of that pool when it asks me what to use as a virtual disk. Which is kinda silly, to me./p pBut these are just minor annoyances, there are much bigger problems: if the modules for kvm (kvm and kvm-amd in my system) are not loaded when virt-manager is loaded, it obviously lack a way to choose span class=capsKVM/span as hypervisor. This is nice, but it also fails to see that there is no qemu in the system, and tries to use a default path, that is not only specific to RedHat, but also very not existing here (code/usr/lib64/xen/bin/qemu-dm/code, on x86-64, just checking the uname!), returning an error that the particular command couldn’t be found. At least it should probably have said that it couldn’t find qemu, rather than the particular path. It would have also been nice to still allow choosing kvm but then telling that the device was missing (and suggested loading the modules; VirtualBox does something like that already)./p pTo that you have to add that I haven’t been able to finish the wizard to create a new virtual machine yet. This because it does not check the permission to create the virtual machine embefore/em proposing you to create one, so it let you spend time to fill in the settings in the wizard and emthen/em fails telling you don’t have permission to access the read/write socket. Which by default is accessible only by root./p pEven though it’s obvious by the 0-prefix that the software is still not production-level, there are also a few notes on the way the interfaces are designed. While it’s a good idea to use Python to write the interface, since it allows a much faster test of the code and so on, and speed is not a critical issue here, as the work is carried out by C code in the background, every error is reported with a Python traceback, one of the most obnoxious things to do for users. In particular for the permission problem I just listed, the message is a generic error message: “Unable to complete install: ‘unable to connect to ’/var/run/libvirt/libvirt-sock’: Permission denied’”; what is the user supposed to know here? Of course virtualisation is not something the user at the first tries with Linux is going to use, but still, even a power user might be scared by errors that appear this way and have attached a traceback (that most users would probably rationally link with “the program crashed” like bug-buddy messages, rather than “something wasn’t as the software expected”, which is what happened./p pOn a very puny level, instead, I have to notice that just pressing Enter to proceed to the next page on the wizard fails, and using span class=capsESC/span to close the windows too. Which is very unlike any other commonly-used software./p pSo to cut the post short now, what is the outcome of my test? Well, I didn’t get to test the actual running performance of span class=capsKVM/span against VirtualBox, so I cannot say much about that technology. I can say that there is a long road ahead for the Virtual Machine Manager software to become a frontend half as good as VirtualBox’s or VMware’s. This does not mean that the software was badly written, at all. The software by design is not bad at all; of course it’s very focused on RedHat and less on other distributions, which explains lots of the problems I’ve noticed, but in general I think it’s going the right way. A more advanced setup for advanced users would probably be welcome by me, as well as an span class=capsISO/span images management like the one VirtualBox has (even better if you can assign an span class=capsISO/span image to be of a specific operating system, so that when I choose “Linux”, “Fedora” it would list me the various span class=capsISO/span for Fedora 8, 9, 10 and then have a “Other” button to take a different span class=capsISO/span to install, if desired./p pI’ll keep waiting to see how it evolves./p /div
Diego Pettenò: Bundling libraries for despair and insecurity

Posted: January 2nd, 2009, 5:30pm CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pemI’ve been told quite a few times that my posts tend to be too long, and boring for most basic users, so for a time I’ll try to use the “extended content” support from Typo, and see how people react. What this means is that the blog post is just summarised on feeds, and on aggregators like Planet, while the complete text can be read by accessing the article directly on my blog./em/p pWhen I started my work a href=http://blog.flameeyes.eu/2008/01/21/and-what-about-imported-librariesreporting bundled libraries/a almost an year ago, my idea had a lot to do with sharing code and just to the side to do with the security issues related to bundled libraries. I had of course first hand experience with the problem, since xine-lib has (and still in part had) bundled a lot of libraries. When I took over maintainership of it in Gentoo, it was largely breaching policy, and the number of issues I had with that was huge. With time, and coordination with upstream (to the point of me becoming upstream), the issues were addressed, and nowadays most of xine-lib bundled libraries are ignored in favour of the system copies (where possible; some were largely modified to the point of not being usable, but that’s still something we’re fighting with). Nowadays, the 1.2 branch of xine-lib already doesn’t have a FFmpeg copy at all, always using the system copy (or an eventual static copy built properly)./p pBut nowadays I started to see that what is obvious to me about the problems with bundled copies of libraries is not obvious to all developers, and even less obvious to “power users” who proxy-maintain ebuilds and just want them to work for them, rather than complying with Gentoo policies and standards. Which is why I think that sunrise and other overlays should always be scrutinised carefully before being added to a system./p pAt any rate, for this reason I’m going to explain in this post why you should not use bundled internal copies of libraries for packages added to Gentoo, and why in particular these packages should not be deemed stable at all./p pThe first issue to discuss is why do upstreams bundle libraries, since knowing the reasoning behind that is often helpful to identify whether it makes sense at all to keep them or not. The first most obvious answer is: to reduce dependencies. For a long time this was the major reason behind xine-lib usage of internally bundled libraries. As it turns out, with time this reason became moot: distributions started packaging xine-lib directly reducing the number of users wishing to build it from sources; even those wanting to build xine-lib from sources would find all the needed libraries in the distributions, most of the times. When this is the sole reason for libraries building, upstream should be very well open to add a configure option (or anything similar to that) to use the system copy, optionally or by default, with fallback to the bundled copy./p pA second reason might be that the library is being unstable when it comes to span class=capsAPI/span; this is probably the first reason why FFmpeg is often bundled in software rather than using the copy on the system; while this is a concern that makes more sense then the one before, it’s still mostly a moot point since it really just requires to fix the issue at the source: get the original project to maintain span class=capsAPI/span compatibility, to provide an span class=capsAPI/span compatibility layer, or to finalise its span class=capsAPI/span. Even when it cannot be helped, because the span class=capsAPI/span is in flux, maintained software fears not the span class=capsAPI/span break; it might be a bit of an hassle but in general it’s feasible to keep the use and the library in sync./p pThirdly, more worrisome, is when the library is modified, slightly or heavily, after bundling; in this case using the system copy might be quite a burden because it will lack the specific changes as made by the project. In this case there is a lot of work involved, sometimes more work that it can be taken care by distributions, and requires coordination of the project’s upstream together with the higher level upstream. This is what happened with xine-lib and FFmpeg: the copy in the xine-lib sources was heavily modified to suit both the build system and the interface requirements of xine, which made it also very difficult to update the internal snapshot. All the interface changes needed have then been pushed upstream to FFmpeg, and the buildsystem changes were made moot by using the default buildsystem (with needed changes pushed upstream) embedded in autotools; and then FFmpeg was entirely removed from xine-lib’s sources./p pNow, on the other hand, the disadvantages of using bundled libraries are probably worse: code duplication means that there is more data to process (both at build time to compile and at load time to store in memory), there is more space used by the binaries, and there are duplicated bugs that need to be fixed twice. A lot of time in xine-lib the problems with decoding something with FFmpeg were solved by just using a newer FFmpeg; why keeping one then?/p pThe most important issue though is about security: when a vulnerability is found in a library like zlib, fixing the library alone is not enough: while that fixes the majority of the software in a system, it’s not going to fix those who bundle it, both a href=http://blog.flameeyes.eu/2008/12/18/software-sucks-or-why-i-dont-trust-proprietary-closed-source-softwareclosed-source/a and open source. For instance, take a href=https://bugs.gentoo.org/show_bug.cgi?id=251109;dzip/a it uses an ancient internal version of zlib; if somebody knows the format well enough, it’s far from impossible to craft a dzip file that contains a deflated stream that can executed malicious code./p pFor this latter issue alone, I’d say that any software bundling source code is not good enough to go stable on its own. Of course sometimes one has to bend the rules because of past mistakes, for instance even though Ruby a href=https://bugs.gentoo.org/show_bug.cgi?id=253276bundles stuff/a, we cannot stop newer versions to go stable; this problem is not a regression. But strongshould/strong stop other broken software from entering portage or at least the stable tree./p pBut it’s not just security, subtle bugs might actually be quite a problem. For instance, you might remember all Java applications failing when libX11 was built with span class=capsXCB/span support some time ago. The problem was due to some stricter checks in libxcb compared to what libX11 have been checking before, but the source of the problem was Xinerama. The problem with that was that Sun bundled an internal copies of libXinerama sources in the span class=capsJRE/span sources, and even though libXinerama was since then fixed regarding that particular issue (the crash with span class=capsXCB/span), it was never updated in the span class=capsJRE/span before the issue became a nuisance for users./p pA very similar issue, also involving span class=capsX11/span (just by chance, it’s not that all the issues involve span class=capsX11/span) is a href=http://bugs.freedesktop.org/show_bug.cgi?id=17431this particular bug in Xorg/a that is triggered when launching span class=capsSDL/span-based applications, because libSDL a href=https://bugs.gentoo.org/show_bug.cgi?id=246177bundles ancient versions of span class=capsX11/span libraries/a./p pAs I said earlier, unbundling is rarely easy; there are subtle issues to be checked out, for instance one has to check if there are changes at all beside eventual build-system related things (for instance to avoid using a full-fledged ./configure), but altogether it’s usually not tremendously impossible. Of course one has to stop thinking “Oh my, what if a library changes and the software breaks?”, otherwise the task gets impossible. Software changes, software bitrots. It’s not by bundling internal copies of libraries that you can stop that. When the compiler gets upgraded, you’re going to have your software break, and you should fix your software; if the C library cleans up the includes, your software might not compile or might misbehave, deal with it. Sometimes the bundled libraries implement protocols and formats that need to work together with some other piece of software; if that changes, the bundled libraries are just going to break further./p pstrongYour software is rarely special enough that you can be exempted from following the rules./strong Even OpenOffice is using lots of system libraries nowadays!/p pBundling and modifying libraries is just like forking a project, and a href=http://lwn.net/Articles/282261forking might not always be the best approach/a sometimes with dead upstream for a project, forking is your only hope; but even in those cases there are nice ways to bundle libraries. If you look at the way a href=https://bugs.gentoo.org/show_bug.cgi?id=253269nmap bundles libdnet/a, you can see that they not only document all the changes they made to the library, but also provides splitted down and commented patches for the various changes, making it possible to adapt it to their need./p pFor proprietary software packages, of course, the matter is different, since you cannot usually unbundle the libraries yourself; but it’s a good idea to ask upstream nicely if they can use system copies instead of internal ones. Mind you, some might be happy to fix their packages not to be vulnerable any longer. Although I guess lots of them might actually prefer to keep them as they are since it’s a cost to them. One more reason not to trust them, to me./p pSo bottom line, if you’re working on an ebuild for a new piece of software to submit for Portage addition, please look well to see if the software is bundling libraries, and if it is, don’t let it enter portage that way. And if you’re a developer who wants to push some ebuild to the tree, also remember to ensure that it complies with our policies and doesn’t bundle in libraries./p /div

← Linux Debian →

Tux news - Linux ubuntu fedora gentoo gnome news » Gentoo

Feeds

Gentoo (5 unread)

Planet Gentoo

Diego Pettenò: PAM authentication for paranoids

Posted: January 5th, 2009, 12:28pm CET by Diego Pettenò (flameeyes)

Diego Pettenò: For A Parallel World. Case Study n.5: parallel install

Posted: January 3rd, 2009, 9:01pm CET by Diego Pettenò (flameeyes)

Tobias Klausmann: A tale of too many parameters

Posted: January 3rd, 2009, 3:12pm CET by Tobias Klausmann (klausman)

Diego Pettenò: Free virtualisation - not working yet

Posted: January 3rd, 2009, 3:27am CET by Diego Pettenò (flameeyes)

Diego Pettenò: Bundling libraries for despair and insecurity

Posted: January 2nd, 2009, 5:30pm CET by Diego Pettenò (flameeyes)