Rich0's Gentoo Blog

The Dark Side of Quality

with 5 comments

Voltaire once said that the best is the enemy of the good. I think that there are few places where one can see as many abuses of quality as you’ll find in many FOSS projects, including Gentoo.

Often FOSS errs on the side of insufficient quality. Developers who are scratching itches don’t always have incentive to polish their work, and as a result many FOSS projects result in a sub-optimal user experience. In these cases “good enough” is standing in the way of “the best.”

However, I’d like to briefly comment on an opposite situation, where “the best” stands in the way of “good enough.” As an illustrative example, consider the excellent practice of removing bundled libraries from upstream projects. I won’t go on about why this is a good thing – others have already done so more extensively. And make no mistake – I agree that this is a good thing, the following notwithstanding.

The problem comes when things like bundled libraries become a reason to not package software at all. Two examples I’m aware of where this has happened recently are media-sound/logitechmediaserver-bin and media-gfx/darktable. In the former there is a push to remove the package due to the inclusion of bundled libraries. In the latter the current version is lagging somewhat because while upstream actually created an ebuild, it bundles libraries. Another example is www-client/chromium, which still bundles libraries despite a very impressive campaign by the chromium team to remove them.

The usual argument for banning packages containing bundled libraries is that they can contain security problems. However, I think this is misleading at best. If upstream bundles zlib in their package we cry about potential security bugs (and rightly so), however, if upstream simply writes their own compression functions and includes them in the code, we don’t bat an eyelash, even though this is more likely to cause security problems. The only reason we can complain about zlib is BECAUSE it is extensively audited, making it easy to spot the security problems. We’re not reacting to the severity of problems, but only to the detectablity of them.

Security is a very important aspect of quality, but any reasonable treatment of security has to consider the threat model. While software that bundles a library is rightfully considered “lower” in quality than one that does not, what matters more is whether this is a quality difference that is meaningful to end users, and what their alternatives are. If the alternative for the user is to just install the same software with the same issues, but from an even lower quality source with no commitment to security updates, then removing a package from Gentoo actually increases the risks to our users. This is not unlike the situation that exists with SSL, where an unencrypted connection is presented to the user as being more secure than an SSL connection with a self-signed certificate, when this is not true at all. If somebody uses darktable to process photos that they take, then they’re probably not concerned with a potential buffer overflow in a bundled version of dcraw. If the another user operated a service that accepted files from strangers on the internet, then they might be more concerned.

What is the solution?: A policy that gives users reasonably secure software from a reputable source, with clear disclosure. We should encourage devs to unbundle libraries, consider bugs pointing out bundled libraries valid, accept patches to unbundle libraries when they are available, and add an elog notice to packages containing bundled libraries in the interest of disclosure. Packages with known security vulnerabilities would be subject to the existing security policy. However, developers would still be free to place packages in the tree that contain bundled libraries, unmasked, and they could be stabilized. Good enough for upstream should be good enough for Gentoo (again, baring specific known vulnerabilities), but that won’t stop us from improving further.

About these ads

Written by rich0

December 6, 2012 at 10:48 am

Posted in gentoo

5 Responses

Subscribe to comments with RSS.

  1. We could really use a way to declare certain files of a package as belonging to a bundled library, so Portage could still manage it somehow. a la http://redmonk.com/dberkholz/2012/11/12/on-package-management-negating-the-downsides-of-bundling/

  2. In relation to darktable, it’s not that the bundled libs make it unpackagable, rather it takes more time to research what changes upstream made to the bundled libs (if any), why they are using bundled libs, etc. Basically due diligence for any package maintainer, anything else is just being lazy. Good enough for upstream is not good enough for Gentoo in many cases, unless you really want to stop caring about respecting CFLAGS, fixing automagic deps, installing in proper places (all seen in darktable), and many other issues. If all users want is speed of version bumping, overlays work perfectly fine until the package makes it into the tree with a little more QA done on it.

    I don’t really understand your overall point since we *do* have unmasked packages in the tree that contain bundled libraries which have been stabilized. Some devs just have higher standards than others and therefore do more of that type of work before putting related ebuilds in the tree rather than via bug reports later. Any dev is free to do the work, but it’s somewhat annoying when devs just bump packages already in the tree while disregarding those types of issues and then often ignore all the related bugs that follow.

    Tim Harder

    December 7, 2012 at 12:52 am

    • Just using your package as an example – not really to pick on it in particular. And it is worth noting that the latest revbump is only a week or two old.

      My concern wasn’t so much with maintainers who choose to self-impose certain standards so much as with those who would impose it on them from outside, or for maintainers who might be afraid to deploy first and improve later for fear of what the community will think of them.

      If another dev is chomping at the bit to get this or another package out sooner, then they should step up and offer to help maintain it. Per some of my recent posts on -dev that should be a genuine long-term commitment, not just a bump-and-run.

      So again, the citing of examples was meant to be illustrative rather than to suggest that individual maintainers are doing a bad job.

      rich0

      December 7, 2012 at 7:51 am

  3. You’re completely forgetting that at least in the case of logitechmediaserver-bin we *know* that some of the bundled code is subject to vulnerabilities that are already fixed in the system libraries, including a known vulnerable version of zlib.

    So either the bundled library is unreachable (so why bundling it?) or it’s exposing a vulnerability (it’s a freaking _server_ software! I don’t really see the fact that “it should only be allowed in a LAN” as a good reason to close our eyes on the matter — have you ever noticed how many things that “should only be allowed in a LAN” are enabled in computers at your local starbucks?).

    And for a while it worked fine with system libraries, but then the maintainer didn’t feel to keep the commitment to fix the ebuild to be at the level of quality of the rest of the tree.

    And it’s nice for people to keep putting words in my mouth that I’m too strict with quality, but I also maintain software that has problems with bundled libraries (Blender) and I wrote about it! I’m not going to remove, or drop the stable, on Blender just because of that. And if you think that’s the only reason I have to wish logitechmediaserver-bin out of the tree, you’re seriously deluded.

    • Per my suggestion, if logitechmediaserver-bin contains known vulnerabilities then it should by all means be handled per the established security policy. If it can’t be fixed within the appropriate window defined in the policy, then it should be masked until it is fixed.

      I don’t think that this would be controversial at all (at least not for most). The controversy on the mailing list was due to the fact that there was no mention of a known security issue at all, and yet it was suggested that we treat it in the same manner.

      As far as LAN-only software and WiFi goes – anybody who binds servers that belong behind a firewall to WiFi interfaces that connect to random networks is taking a huge risk. It does not shock me at all that it happens, but only education can fix that.

      rich0

      December 7, 2012 at 7:47 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: