When the Personal Package Archive (PPA) system was brought out of beta in November 2007, it was heralded as a game changer for Free Software developers within the Ubuntu community and beyond.
The PPA system was designed to make it easier for developers to get their software packaged and available to users for testing, thereby speeding up project development and delivering higher quality software.
After nearly four years of PPAs, I thought I’d find out out whether the original objectives of the PPA system were still the primary focus – or had PPAs taken on a whole new role, filling a gap that’s traditionally been a sore point for Ubuntu?
Initial demand for the PPA system
Right from the outset, the idea of the PPA was to make it easier for developers to get their under-development software into the hands of community testers for wider scale testing. As Matt Zimmerman, Ubuntu’s Chief Technical Officer explained at the time:
"A PPA allows a developer to form a community of testers who are interested in their changes. The testing community can install the packages, run them for the test period and then remove them cleanly from their system.”
Packaging software has always been a difficult endeavor, requiring a certain skill so pronounced that it defines a class of contributors in itself. Even if you had managed to package some software for extra testing, there was the issue of distribution. The process of landing software in the official repositories is time consuming, bureaucratic, and since we are dealing with development quality code, not something that the main Ubuntu repositories were designed to store anyway.
Ubuntu is of course shipped with certain tested versions of software to enable a default and stable experience. Other than posting on personal or project blogs, before the existence of PPAs, the only way to conduct efficient wide-scale testing was by announcing new updates via mailing lists or IRC, when community testers could download .deb packages or compile software from the source.
An easier way
PPAs were a breath of fresh air – not only did they make packaging simpler but they also promised easier (and much wider) distribution, and at the same time reducing the barrier to entry for testers. Anybody could simply add a PPA to their software sources list, fetch the GPG key, run an update, and then the software was available to install like anything else.
Over the years, PPAs became increasingly easier for mainstream users to add to their system. When Ubuntu 9.10 was released at the end of 2009, all PPA management could be accomplished via a graphical interface which even fetched the security key and kept the Terminal hidden out of sight.
One of the major disadvantages of Ubuntu, being a non-rolling release distro, has been that post-release software updates simply don’t happen. If a new version of Firefox is released midway through an Ubuntu cycle (like Firefox 4 in March this year), there’s no easy way for users to get their hands on this update without manually installing a .deb, building from source, or – you guessed it – adding a PPA.
Better yet, come upgrade time, a lot of distribution upgrades suffer from broken packages due to hefty amounts of PPAs and distinctly erratic version numbers for applications caused by the manual installation of PPAs. One of the leading causes of broken upgrades is failures in the packaging system due to complicated mixes of non-PPA and PPA installed applications.
I talked to Canonical’s Brian Thomason, who maintains the Partner and For Purchase repositories. Brian suggested that PPAs are useful for delivering new and stable updates, provided they’re packaged correctly.
“In general people just throw new versions of things such as Firefox into a PPA rather than taking care to have it Conflict/Replace with the package in the main repo. If Firefox 3 is in the archive under the package name firefox, and a PPA maintainer releases Firefox 4 under the same package name, firefox, yes, that could potentially lead to distribution upgrade problems later.”
Recently the Ubuntu team have been looking at ways of delivering post release software updates for major apps during a release lifespan, but there’s still a very active culture of PPA abusers – those who use the PPA system to their advantage to distribute newer versions of software, rather than using the PPA system as it was originally intended: testing development versions of your own personal projects. PPAs have become Public Packaging Archives.
Banshee is the default media player in Ubuntu and is a very actively maintained project with many developers and regular releases. Providing the user doesn’t add the Banshee PPA, the version of Banshee that shipped in Ubuntu 11.04 will remain the same throughout the cycle for six months until the user upgrades to Ubuntu 11.10.
In the case of Long Term Support (LTS) releases, the wait can be up to two years.
The majority of users who have added the Banshee PPA have done so not because they’re actively testing Banshee and submitting bug reports, but because they want the latest software on their stable Ubuntu install. This suggests that the problem isn’t actually with PPAs, but rather with the lack of stable software updates post-release – a niche that PPAs have unwittingly filled.
Security
"Many developers want to modify existing packages, or create new packages of their software. The PPA service allows anyone to publish a package without having to ask permission or join the Ubuntu project as a developer.” – Christian Reis, Launchpad Release Manager, 2007.
One of the benefits of PPAs is that nobody has to “okay” them. They’re untrusted. This allows developers to quickly make their software available for testing while minimizing any checking procedures, which takes time. It means that anyone with a Launchpad account can create a malicious PPA and disguise it as some other software, perhaps a fork of an already popular application.
Of course, when a user adds a PPA they’ll need to enter in their password – a sign that what they’re doing could potentially harm their system, so you could argue it’s the users’ fault if they install something that’s not checked out beforehand.
The problem with this is that the password prompt in Ubuntu is somewhat similar to the story of the boy who cried wolf. Ubuntu prompts for your user password on so many occasions, for many it’s built into their daily usage and thinking twice before entering a password may be something users don’t do.
Coupled with the fact that there is no distinguishable difference between installing software through trusted repositories, such as the main repository, and then installing software through a PPA. Both require the same password prompt – there’s no indication that one could be more malicious than the other even though this is in fact the case.
Why not just tell people not to use PPAs?
Lately, OMG! Ubuntu! has been criticized for posting installation instructions for PPAs that – due to the nature of the PPA system – could contain untested or malicious software. Of course, OMG! Ubuntu! checks out PPAs before recommending them, and even then, each set of PPA installation instructions are accompanied with a disclaimer.
Can OMG! Ubuntu! be held accountable for what is not only a hypothetical situation (because so far, none of our readers have complained about any malicious activity caused by a PPA we promote), but also one where the problem doesn’t lie with us, but with the current software distribution setup that Ubuntu employs?
Websites such as OMG! Ubuntu! exist to make the users’ life easier, and currently, the easiest way for users to get the latest stable updates of their favourite applications is via a PPA. Whether or not that’s the most secure way isn’t our concern – PPAs are a product of Launchpad and Canonical. They weren’t created by us.
Perhaps Canonical should employ a full time person to explain to news outlets that advocating PPAs isn’t something they should be doing – after all, even as recently as this month, an article in The Guardian mentioned how easy it was to add third party software to Ubuntu. The author mentioned nothing about the security implications of doing so.
As Ubuntu grows, the likelihood that somebody creates a PPA purporting to be providing wholesome and trustworthy updates, but in actual fact runs malicious scripts instead is an ever increasing threat, and rather than trying to police the media with the argument “don’t install PPAs, they could be dangerous” it would be better to fix the problem deeper down.
Clearly there is a demand in Ubuntu for easy installation of newer software updates. The versions provided in official channels can often be as much as two years out of date.
PPAs have become a convenient solution to a problem which has never been addressed, and they’re serving a purpose for which they were never designed. As a side effect, the media is being blamed for promoting them due to their convenience, because there simply is no other easy way.
No comments:
Post a Comment