Ubuntu's multisearch surprise

Posted Aug 8, 2009 7:18 UTC (Sat) by cuboci (subscriber, #9641)
In reply to: Ubuntu's multisearch surprise by MattPerry
Parent article: Ubuntu's multisearch surprise

> Worse, they fiddle with them and change them before they package them up, so what you get may not be what the developers wrote. Just look at the mess that was caused when some Debian developer screwed around with OpenSSH. Or how Red Hat hosed up Perl's performance and didn't fix the issues for years.

That's like saying upstream doesn't make mistakes and all bugs are introduced by distributors. Just think of all the security holes distributors patch before any upstream developer even takes notice of them.

Also, I wouldn't trust upstream developers to package software correctly for the distribution I use unless all distributions are the same - in which case there wouldn't be any. And just look at the state of software packaging on Windows. Same base for all, no package management that deserves the name.

Distributors only providing a base and upstream developers packaging the software themselves (which is a lot of work, btw!) would probably lead to something similar.

to post comments

Ubuntu's multisearch surprise

Posted Aug 8, 2009 16:59 UTC (Sat) by MattPerry (guest, #46341) [Link] (4 responses)

> That's like saying upstream doesn't make mistakes and all bugs are
> introduced by distributors.

It's not like that at all. Each person who modifies the code increases the chance of introducing errors. I'd prefer that the developers of the software review the patches that go into a program I use. Mistakes will still happen, but at least a process is in place where the people who know the program best can review what goes into it.

The Debian SSH problem is a great example. The packager did seek feedback from the OpenSSH team about their change and was told it was okay. But they continued to make further changes to a similar piece of code that introduced a security issue. Had that additional change been reviewed by the original developers, the chance of it being caught would have been increased.

> Just think of all the security holes distributors patch before any
> upstream developer even takes notice of them.

That sounds like a communication problem.

* Why did the distro packager not notify the upstream developer of the problem and coordinate a fix?
* Do other distro packagers know about this problem?
* Will this one distro have the fix while other distros and the official source will be vulnerable?
* How does the distro packager know that their fix doesn't introduce another bug, security hole, or damage functionality?

If multiple distro packagers know about the problem and are applying the patch, you are then duplicating work among distros. See drag's comment above about all of the effort that is duplicated and wasted between distro packagers doing the same task over and over.

> Also, I wouldn't trust upstream developers to package software correctly
> for the distribution I use unless all distributions are the same - in
> which case there wouldn't be any.

I'd trust them to package things if we created standards and processes to make packaging easy for them. The Linux Standard Base is supposed to provide such a standard. Maybe we as a community need to revisit such standardization and bring pressure upon distros and application providers to properly conform to said standards.

> And just look at the state of software packaging on Windows. Same base
> for all, no package management that deserves the name.

Windows' package management may pale in comparison to what Linux-based package systems provide, but it's far from broken. From an end-user perspective, it may be simple but it works. For example, I can download Firefox or OpenOffice from the developer's web site and use the same package to install on a variety of Windows versions without issue. Removing a package is equally easy and problem free.

> Distributors only providing a base and upstream developers packaging the
> software themselves (which is a lot of work, btw!) would probably lead
> to something similar.

Plenty of open source and free software vendors successfully package and distribute working install packages of their software for Windows and they install, work, and can remove flawlessly.

Examples: Cygwin, OpenOffice, Vuze, Firefox, CDex, Calibre, Pidgin, VirtualBox, Vim, Emacs, XEmacs, OpenVPN, GIMP, VLC Media Player, Audacity, Scribus, Ekiga, AbiWord, Apache, PHP, PostgreSQL, MySQL.

So they can successfully do this for Windows but doing the same for Linux distros is somehow not possible? I don't believe that for a second.

Ubuntu's multisearch surprise

Posted Aug 9, 2009 10:29 UTC (Sun) by dtucker (subscriber, #6575) [Link] (1 responses)

> The packager did seek feedback from the OpenSSH team about their change
> and was told it was okay. But they continued to make further changes to a
> similar piece of code that introduced a security issue.

The incident I think you're referring to (http://lwn.net/Articles/282038/) was a change to OpenSSL, not OpenSSH. OpenSSH was impacted because it uses OpenSSL's RNG functions but it wasn't the location of the change in question.

Ubuntu's multisearch surprise

Posted Aug 11, 2009 14:46 UTC (Tue) by MattPerry (guest, #46341) [Link]

Thanks for the correction. I knew it was one of those but had forgotten which one.

Ubuntu's multisearch surprise

Posted Aug 10, 2009 0:52 UTC (Mon) by ringerc (subscriber, #3071) [Link] (1 responses)

FF, OO.o, etc work on Windows because they bundle every dependency directly into the app download. They each maintain private copies of libpng, libjpeg, gtk, etc etc etc.

These libraries cannot be shared in memory and use extra disk space. Who cares these days, right? However, the separate libraries mean that the app vendor must issue a security update if any of the libraries they use in the app suffer from a security hole. Each vendor must update its app(s) separately, since they have private copies of the affected libraries. The poor user has to find out about these updates - or is deluged with hard-to-verify-as-authentic update dialogs from a bunch of different apps.

App auto updates are dangerous when the user has no way to verify that (say) the OO.o update dialog really is from OO.o, not a web page trying to trick them into downloading malware. I've already seen fake Adobe Updater dialogs, so this is far from a theoretical problem. To you or I it might seem fairly obvious how to check, but most users just haven't the foggiest, and tend to either reject all updates (leaving their machine with gaping security holes) or accept them all (opening them to malware risks).

FF works around this by not giving the user a choice. That's fine so long as the updates are trivial, you're absolutely certain they'll never break anything, and the user has the access permissions to actually install the updates. The latter, however, is often an issue in FF installs, and tends to leave users confused.

An OS-provided central secure update channel would help mitigate these issues. Think "Microsoft Update" but with 3rd party providers allowed to subscribe their apps. This would put MS in the implied position of being expected to vet all those updates, though, and they're never going to allow it. WHQL drivers already give them quite enough trouble.

As if the security issues weren't unpleasant enough, there's also the fun of "DLL hell" or "shared library hell" caused by ABI-incompatible libraries with the same soname being loaded into the one executable. This would seem trivial to avoid by bundling all your own libraries, and these days _mostly_ is, but you still run into unpleasant issues with LoadLibrary/dlopen(), user PATH / LD_LIBRARY_PATH settings, etc.

Essentially: Yes, the Windows app distribution model works, but it (IMO) suffers from a collection of annoying flaws just like the Linux distro model. They're just different annyoying flaws.

Ubuntu's multisearch surprise

Posted Aug 10, 2009 16:26 UTC (Mon) by Cato (guest, #7643) [Link]

Re Firefox not giving users a choice over updates: it's quite easy to disable all extension updates through the Preferences dialogue box, but of course that could mean they miss a security update. What would help is if extension authors categorised updates as security or other, and Firefox subscribed you to security updates only by default.

Ubuntu's multisearch surprise

Posted Aug 10, 2009 11:28 UTC (Mon) by mjthayer (guest, #39183) [Link]

As per my comment above, a better solution might be for the packagers to work directly on the upstream source instead of on local trees. That way the upstream source supports packaging for all distributions interested in shipping it, packagers' modifications get reviewed by the upstream developers and packagers don't have to duplicate the efforts of other packagers. It complicates version management a bit, but that just boils down to packagers picking a given stable branch of the programme to be packaged for a given distribution release, and ensuring that that branch is maintained for as long as they need it. Which they have to do anyway, but usually with a private distribution branch.