| |||||||||||||
|
| |||||||||||||
Not saying it's right, but..Not saying it's right, but..Posted Dec 2, 2009 1:03 UTC (Wed) by dw (subscriber, #12017)Parent article: Callaway: Chromium: Why it isn't in Fedora yet as a proper package
..the only people I ever hear complaining about bundled libs are people packaging free software. At the same time, these are the same people who layer other peoples' codebases with unreviewed patches that end up installed on peoples' desktops labelled with the same name as the 'official' tree, often with comedic effect (e.g. in the Debian OpenSSL fiasco).
Going from my reading of LWN, Fedora is one pot that should not be calling other kettles black in the release engineering department, especially when those other projects are likely to have much better infrastructure in place for dealing with things like security bugs in highly exposed software.
But fork the tree all you like, layer it with unofficial patches to use the 'system libs', feel free to create yourself an entirely unique self-supported attack surface and force it upon your users, all because you know just enough about shared libraries and how they're supposed to be Good(tm) to shoot yourself in the foot.
(Log in to post comments)
Not saying it's right, but.. Posted Dec 2, 2009 2:37 UTC (Wed) by joey (subscriber, #328) [Link] Go read this and come back. I'll wait.So, which do you prefer, evil stupid linux distibutions messing about with shared libraries, or holes in zlib remaining exploitable for years because hundreds of packages embed their own copy?
Not saying it's right, but.. Posted Dec 2, 2009 3:01 UTC (Wed) by dw (subscriber, #12017) [Link]
Right, but I don't count many of those as equipped with a security team able to act quickly. As I alluded to, I trust Goog to respond faster and more maturely to security holes in a heavily exposed application like Chrome than I'd ever trust any distribution.
In principle it's good to have as little as possible duplication of code within a distribution, but turning this into a hard rule is just stupid. Perhaps we should patch forked zlib out of the Linux kernel, since it might have vulnerabilities too? Of course doing so would be stupid, both because the kernel team are (mostly) very on the ball w.r.t. security issues, and also, out of sheer practicality.. the effort and hoops involved, if not impossible, would be ridiculous and probably lead to problems all of their own.
I'd rather have a non-crashy browser supported by a proven security team, with code I can fetch easily from chromium.org rather than tucked away in some .diffs somewhere on redhat.com, that doesn't suffer a performance hit compared to official builds because it depends on some shared libs a bunch of smelly nerds update whenever they feel like it, than one that follows some rule to the letter and ends up suffering from such problems.
Not saying it's right, but.. Posted Dec 2, 2009 3:19 UTC (Wed) by dw (subscriber, #12017) [Link]
Hate to reply to my own comment, but perhaps a little more insight:
I guess this comes down to ones' notion of package purity, for me the purity is in whether bytes reaching the instruction decoder on my CPU are the very same bytes the original engineer intended, and the memory layout isn't randomly changing because of some extra field appearing in some struct in say, the system libpng. Too often I think the regressive boxes-and-arrows notion of purity is more damaging than it is good. This is just one example. I'm all for having those libraries live in chromium.org's RCS if it guarantees a working, stable, predictable product at the end of the day.
Also, some of the examples in that list are just ridiculous. Oh noes, your 'fork' of ConfigParser.py is a security risk! You must depend on a version of Python recent enough to have this in its standard library, otherwise no packages for you. And if any existing environment has code running just fine on Python 0.0001 and has done for 100 years, to hell with you, this is a change required for security and stability!
It's just ass-backwards.
Not saying it's right, but.. Posted Dec 2, 2009 3:31 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
"I'm all for having those libraries live in chromium.org's RCS if it guarantees a working, stable, predictable product at the end of the day."
The problem is not that. The problem is that Chromimum doesn't have a *option* of building against the system copies instead of its own bundled versions and bundling doesn't guarantee stability or predictability. Far from it.
Build and participation Posted Dec 2, 2009 15:38 UTC (Wed) by dmarti (subscriber, #11625) [Link] A straightforward, reasonably fast build (using system libraries where possible) is an invitation to participation. A tweaky build, or a build that takes a long time because every user has to rebuild a fresh copy of lib*, is a KEEP OUT sign. After all, what if you report a bug, and they ask you to pull the latest version to test a fix, or apply a patch, or bisect?
Not saying it's right, but.. Posted Dec 2, 2009 10:55 UTC (Wed) by epa (subscriber, #39769) [Link]
Tom C's blog is not saying that you can't run Chromium (or Chrome) on Fedora; it just outlines the difficulties in packaging it to comply with the Fedora guidelines. Those guidelines (or 'package purity') don't prevent you from downloading Google's build of their browser and installing it, perhaps even by adding Google's repository to your yum sources list. However, part of the raison d'etre of Fedora (and other Linux distributions) is to have software packaged in a standard way; if it's more important to keep the vanilla upstream 'product' for each application then perhaps Fedora is not the distribution to choose.
I think the Fedora people have enough experience with building and maintaining a large distribution that I trust them when they say bundled libraries create a real (rather than purely theoretical) maintenance burden.
There is something to be said for having the exact same binary blob running on your system as the upstream project supplied, and the same as most other users are running. It does in some ways narrow the range of problems and bugs that can occur. It has been suggested before (I remember the Linux Hater advocating the same thing) but for whatever reason it isn't a popular way of doing things in the free software world.
Not saying it's right, but.. Posted Dec 2, 2009 21:26 UTC (Wed) by nevyn (subscriber, #33129) [Link]
> As I alluded to, I trust Goog to respond faster and more maturely to
> security holes in a heavily exposed application like Chrome than I'd ever > trust any distribution.
How? By having their own updater? That's fine, they can release a giant blob
But IMNSHO, if "yum --security update" doesn't update all security errata
And before you want to say you think Google will produce a better repos. and
Not saying it's right, but.. Posted Dec 2, 2009 5:52 UTC (Wed) by sjlyall (subscriber, #4151) [Link]
A fun one I've is when (usually java) apps embed the timezone data files (along with their other libraries).
So when the government decides to change the daylight saving date the OS/distribution will be fixed but come the change you find your app is still one hour out.
Not saying it's right, but.. Posted Dec 4, 2009 18:12 UTC (Fri) by alankila (subscriber, #47141) [Link]
If linux distributors want to mess with the things they package, then feel free to do so. I guess that's what they are going to do, with their guidelines and all. What irritates me is the whining that everyone else is not making your job easy for you.
Not saying it's right, but.. Posted Dec 4, 2009 18:26 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
pick your poison
developers have the right to make things hard for the distros, but if they choose to do so they don't have the right to complain that the distros don't include their program and include a competing program instead.
Not saying it's right, but.. Posted Dec 7, 2009 3:58 UTC (Mon) by alankila (subscriber, #47141) [Link]
Perhaps we just need different kind of distros.
Not saying it's right, but.. Posted Dec 7, 2009 4:16 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Are you volunteering? Talk is cheap.
Not saying it's right, but.. Posted Dec 7, 2009 14:56 UTC (Mon) by alankila (subscriber, #47141) [Link]
My trollish response was just expressing a dissatisfication that there does not seem to be such a thing as a stable linux platform. Something that contains pile of software that tries not to change for a few years, and to which you can dump large code blobs like eclipse, or chromium, or whatever, without that distro's contributors going ballistic about how everything is not done according to their guidelines.
In short, I'd like to see a linux like windows: one which is as minimal as possible and where it is an endorsed practice to install 3rd party software, and such installed software exists, will work, and will continue to work for as long as humanly possible. If such a distro does decide to package proprietary software, it acts merely as glue and distributor channel, and doesn't spend years changing/breaking any of it, or removing useful blobs of functionality, or whatever.
Why do I think this way? Because I believe the open source community is not able to write drivers for all the new hardware, is not able to write decoders for all interesting codecs out there, is not able to keep things working even if someone does write such software. Proprietary code tends to bitrot at an alarming rate, and open source code bitrots and gets depreciated as well. I have had to throw out networking cards which no longer have working drivers, no matter they were once driven by open source code. Stability would be great. Rewriting the community to respect proprietary code, and the constraints such code is written in would be even better.
Not saying it's right, but.. Posted Dec 8, 2009 11:55 UTC (Tue) by mpr22 (subscriber, #60784) [Link]
Doesn't the "pick a version of RHEL and stick with it" model basically fit the "Something that contains pile of software that tries not to change for a few years"?
Not saying it's right, but.. Posted Dec 9, 2009 14:32 UTC (Wed) by alankila (subscriber, #47141) [Link]
True, I suppose. Now if only such a thing also exposed a functional stable driver ABI for things like wlan cards and graphics drivers...
Not saying it's right, but.. Posted Dec 10, 2009 0:44 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
RHEL also has a "stable kernel ABI" essentially because it is the same base kernel with backported patches till the end of the release.
Not saying it's right, but.. Posted Dec 2, 2009 2:47 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
The reason that distributions are the ones who worry about this most is because they are the ones with a long history of experiences that guide their behaviour.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libra...
https://fedoraproject.org/wiki/Staying_close_to_upstream_...
Fedora has guidelines that cover not bundling system libraries but also one that avoids deviating from upstream. The net result is that upstream often do change their codebase to accommodate. Anything else requires special precautions from the security team and generally is a hassle.
|
|
||||||||||||