The GNOME project is currently readying its 3.2 release, the first
update to the re-vamped infrastructure and environment introduced in April
2011. Although many minor enhancements and changes are slated to roll
out with 3.2, the one with the greatest potential to affect end users
is the extensions mechanism for the GNOME Shell desktop interface.
When 3.0 was released, a large slice of the negative criticism it
received centered around the difficulty of customizing GNOME Shell when compared
to the GNOME 2.x panel and menu system. The placement and orientation of
GNOME Shell's interface elements was fixed; fonts, key bindings, and icons
could not be changed; popular informational applets and controls were
missing (and there was no facility for bringing them back); there were no
UI or window-manager themes, et cetera. A stopgap measure called Gnome Tweak Tool appeared
later that restored user control over a number of basic settings, but only
for a fixed set of options.
In the months since, that extension system has slowly begun to take shape. Initially, individual developers would announce extensions on their personal blogs, which were periodically rounded-up on third-party discussion-and-review blogs. That process made locating them difficult, and knowing which ones to trust dicey. An official collection is now hosted in the GNOME Git repository, currently consisting of nine extensions, but it became clear in recent months that a real extension infrastructure would be needed — to handle hosting public extensions, validating and reviewing code, and providing users with a simple way to install and uninstall their selections from within GNOME.
The foot with a sweet tooth
is the codename for the new GNOME Shell extension infrastructure project.
The user-facing front end of the system is a planned extension-hosting web
site à la Mozilla's addons.mozilla.org, at which visitors can
search for and download extensions. The URL for the site is variously
reported as extensions.gnome.org or extensions.gnome3.org, although neither
is active yet. There will be (at least) two substantive differences
between the GNOME extension site and Mozilla's Add-Ons repository,
While one possible solution would be to limit the installation of extensions
to a specialized application, the current scheme is to access to
the extension site with any modern browser, and use other measures to
detect and block malware. A sticking point in this approach is how to
permit the site's web application to safely learn which Shell extensions
are currently installed (and at which version numbers) in order to
present the correct options to the use in the UI (i.e., "Install" versus
"Uninstall / Upgrade"); it is also necessary to create a mechanism to
actually install extensions from the browser.
To provide those capabilities, some sort of go-between
is required, perhaps a local process that can speak HTTP to the browser,
although there are of course inherent security risks to running a local
server that responds to queries about the local filesystem. On the
extension site's side of the equation, the plan is to implement a code
review policy with cryptographically-signed uploads of each extension.
Reviewers will only be responsible for checking new extensions for
malicious behavior, not grading them on importance, functionality, or
The GNOME Shell discussion list has been debating several approaches to the extension-signing and review-process pieces of the puzzle. Owen Taylor's preferred plan involves two signatures: one from each reviewer, and a separate one from the site — although he noted that the manual steps could constitute a weak spot.
In theory signatures can offer a layer of security that is independent of the security of the hosting of extensions. It's hard for me to wrap my head around a way to make that practical, if we want to be able to review and approve extensions through the web UI.
Schemes I can come up end up with end up with something like:
- Reviewers download and review extensions locally, then sign them with their GPG key.
- An administrator takes the signed extensions, checks the reviewers signature and then adds the official GNOME signature.
That would be very secure, but it also creates manual steps and points of failure that would likely make the system just not work in practice.
We shouldn't forget either that our opinion about whether an extension is safe can change over time. A signature only means that that exact code base passed review at one point in time.
Extension security is an issue, but as was noted elsewhere in the thread, it is not a greater security risk than that of running any other desktop application.
As the example extensions linked to above show, however, a fair number of GNOME Shell extension authors appear interested in substantially changing the desktop experience. The GNOME Shell team seems to be taking a hands-off approach (noting on the Sweet Tooth wiki page that the project will not endorse or support third-party extensions).
Hopefully making that policy prominent on the extensions site will appease the camp that worries about customization diluting the "GNOME brand," but it does leave open the possibility of mutually-conflicting extensions. So far there appear to be no safeguards in place, although there was some discussion about an SELinux-like permission system. Keeping track of permission sets is primarily a security policy tool, but would also assist in managing collection of extensions.
The developer angle
Looking Glass offers a way for aspiring extension writers to explore the GNOME Shell environment. One can select items in GNOME Shell with the mouse and copy the underlying GObject structure to the Looking Glass evaluator, and there is a special function to slow down animations for easier debugging. But it still is not complete enough to serve as a full development environment.
A bigger issue is that GNOME Shell still lacks comprehensive documentation of its structure, methods, and conventions — despite the fact that such documentation is part of the official roadmap. The extension system is potentially powerful, but the only way for outsiders to learn how to write extensions is to hunt for tutorials and examples on individual blogs. Some of them are quite good, such as Finnbarr Murphy's. But without a real effort to maintain official documentation, they rapidly fall out of date.
Providing add-on developers with adequate resources is an area where Mozilla excels with its Mozilla Developer Network sites; GNOME will need to play catch-up in order to grow a healthy GNOME Shell extension community.
Now that the freeze for 3.2 is upon us, and the extensions site is still not up and running, it appears that the framework will be relegated to a "soft-launch" in the 3.2 cycle. Taylor described it as "a bit of a stealth-beta for this release ... something we're still working on, something we don't advertise as a release feature, but something that you can already use."
Perhaps that is for the best. Although the extensibility of GNOME Shell is promising (perusing the extensions already written is quite an experience), the human side of the framework still needs work. One only needs to take a look at the public response to GNOME 3.0 to see how poor messaging can undermine a technical success.
The 3.0 public relations and marketing blitz completely failed to communicate to users and developers that an extension mechanism was in the works, or even a possibility for the future — it got no mention in the release notes, the talking points, or even the design documents. GNOME developers have been talking about GNOME Shell extensions in the run-up to 3.2, but with API documentation and developer outreach still missing in action, the risk is that yet another major release will pass with the project missing an chance to attract coders and strengthen its software ecosystem.
to post comments)