User: Password:
Subscribe / Log in / New account


Arch Linux and (the lack of) package signing

March 23, 2011

This article was contributed by Nathan Willis

The Arch Linux user and developer community has been engulfed in sharply divisive debate recently over the issue of package signing. It started when an Arch user blogged about the distribution's lack of package signatures, the security risk it created, and his own frustrations with the core developers' response to the issue. The ensuing argument has since spread to include Arch's development model and a variety of leadership questions, but the root problem remains unsolved: there is still no mechanism to verify the authenticity of "official" Arch Linux packages.

Arch Linux is a non-commercial distribution that de-emphasizes ease of use in favor of emphasizing the "responsibility" of the user to maintain the system properly, and providing "simple" and "code-correct" tools rather than striving for convenience. That philosophy evidently attracts a healthy number of users and contributors, but to some users, the project in practice misses the mark in the important area of security. Arch Linux practices rolling releases, with new packages pushed out as tarballs made available on the primary project server, and mirrored on close to 100 sites around the globe. Although the official installation guide and download page both emphasize the importance of examining the checksums of downloads, no packages are signed by individual developers or by the main project server.

To blogger IgnorantGuru, this constitutes an unacceptable security risk. In February, he blogged about his concerns, noting that without a method for Arch users to verify that a package is unaltered, packages can be replaced with Trojan-horse-laden code. This can happen if the primary server is compromised, but also at any of the mirrors, at network proxies or caches, on local storage, or even through man-in-the-middle hijacking of the download request. While package authentication might not have been important in Arch's early days, he said, the number of contributors and mirrors has grown so much that without signatures, the distribution and its users are sitting ducks.

Package signing protects against attackers' ability to tamper with or replace an uploaded file by providing an independent way for other people to verify that the binary has not been altered since the time it was signed by the developer. If a file server's security is compromised, a simple checksum (such as an MD5 or SHA1 hash) can be replaced with a new hash that matches the tampered-with binary with virtually no additional work for the attacker. That is because a hash is a function of the file contents alone; a digital signature is a function of both the file and the signer's private key. Thus, its authenticity can be verified using the file and a copy of the corresponding public key from a public key server.

Almost all prominent Linux distributions use package signing to allow users and system administrators to verify the integrity of packages. Typically, package uploaders use a private GPG key to sign the package before it is pushed to the release server, and the user's package installer includes support for automatically retrieving the corresponding public key and checking the signature. Support in the package manager itself is not mandatory, however; simply including a cryptographic signature as part of each package's metadata would permit security-conscious users to manually verify that packages have not been tampered with.

IgnorantGuru made that point in a message to the mailing list for developers of Arch's package manager Pacman. There he also lamented what he said was the low priority given to package security by the developers. The topic had come up before, but no one acted on it, and several of the core Arch developers dismissed the subject as an unimportant one that they were not willing to work on personally. IgnorantGuru subsequently asked for the addition of signatures to package metadata (without adding simultaneous support for checking them), and the core developers replied that he should take the issue up with the maintainers of the Arch mirrors he used.

Process, and the lack thereof

Furthermore, IgnorantGuru lambasted the dismissive attitude of the core developers towards the security issue in general. He quoted several of them directly, including comments such as "For me it makes not a big difference if a package is signed or not. It's a nice to have feature and I would be glad if someone would implement it. But for me it has a very low priority," and "Minor performance issues interest me a hell of a lot more than package signing."

A few, he said, did take the issue seriously and had submitted patches to Pacman, but core developers refused to act on them. In the comment thread that followed, supporters came out on both sides, and IgnorantGuru expounded on his claims of key developers resisting the idea, if not openly trying to derail it. He linked to two bug reports he had filed (the second in response to a comment on the first), noting that Allan McRae seemed to be actively trying to keep package signing improvements out of Arch. McRae, he said, repeatedly claimed that he had no interest in package signatures (and frequently stated that anyone who cared to could submit their code), but sought out every discussion of the topic and tried to quash others' efforts to work on a solution.

In the second first bug report, IgnorantGuru even suggested a lightweight solution that involved only signing the main server's package database, which would not protect users in the event that the main server is compromised, but would at least allow them to verify that a given mirror had not altered the packages it hosted. McRae countered that this approach still left other attack vectors open (such as the master server itself being compromised and the signatures and database forged), thus it was not worth implementing, and that waiting for full support to come to Pacman was preferable. IgnorantGuru responded, in effect, that this line of thinking is making the perfect the enemy of the good, and that adding lightweight signature support provided at least a substantial improvement over "no signatures whatsoever." McRae also argues that the package signing plan in the bug reports is "sub optimal" and proposes a different approach instead, concluding with a list of unanswered questions about the new approach. IgnorantGuru calls this an attempt to derail real work by starting a bike-shedding argument.

In addition to laying out the technical arguments, IgnorantGuru described how his attempts to discuss package signing on the official Arch discussion forum had been shut down by forum moderators. The threads were closed, and then moved to a "dustbin" forum section that is not visible to unregistered users. Subsequently, IgnorantGuru's account was suspended for eight weeks by the moderators, and his IP address blocked.

IgnorantGuru posted a copy of the message that prompted his forum ban on his personal blog. In it, he quotes McRae's assertion that he would accept Pacman patches from other developers, and his assertion that "as usual" no one submitted any. He then describes patches sent by himself and other Arch contributors, and what McRae and other core developers did to prevent merging them. This second post covers similar ground as its predecessor, but the comment thread provides even more detail, as McRae eventually joins in.

As you would expect, there is a lot of heated language between the two, which can make it difficult to separate out the nucleus of each side's complaints. It is clear, however, that other Arch contributors have proposed virtually the same package signing plan as IgnorantGuru in the past, at least as far back as 2008. The core developers have never acted to add signature-checking to Pacman, even though patches have been submitted, yet at the same time have resisted all "interim" solutions as a waste of effort, on the grounds that Pacman is the proper place for package signature work.

For his part, IgnorantGuru posted a Bash script on his own site that allows a user a small amount of integrity checking by comparing the checksums of a package from multiple Arch mirrors. In the weeks since the original post, IgnorantGuru announced that he had given up on the hope that the core developers would ever adopt a package signing solution, and would be moving to a new distribution with a better security model. Most recently he posted about Gnuffy, a fork of Arch Linux that incorporates package signatures and other ideas shunned by the Arch leadership.


In the final analysis, Arch users are exposed to a security threat both by the distribution's lack of package signing and by the core developer's resistance to adopting it. However much the Arch "philosophy" says each user is responsible for his or her own system, IgnorantGuru is correct in his first blog post when he observes that without signatures, the distribution's infrastructure is vulnerable to every exploit found in every other system on the path between the main project server and the user's PC. Any exploit on the OS used by the HTTP or FTP mirror server can allow an attacker to replace an Arch package, and the user has no way to even detect that the change has been made. A network-based man-in-the-middle attack does not even require finding a root exploit on one of the servers; it could be performed at a router or network access point.

As for McRae and the other core developers resisting outside work to implement package signatures, there are at least two levels at which their recent statements are troubling. First, they (and commenters taking their side) invariably bring up the "stop whining or start coding" retort, or its kinder cousin "patches welcome."

In theory that reply encapsulates the open source approach — anyone with an itch can scratch it — which is true on the surface. But it overlooks the reality of distribution maintainership: some tasks, such as security, are vital to the health of the project, even though they might not be anyone's idea of fun. In addition, as the Arch developers' responses have shown, the gatekeepers to a project can still prevent new code and patches from getting accepted if they so choose.

That of course is the second level at which the core developers' resistance is troubling: the fact that they would prevent security patches from going into the project. Some on the anti-signature camp argue (essentially) that if you don't like any decision made by the core developers, you should leave, and cite Arch's "not for the faint-of-heart" philosophy as justification. But that is in direct opposition to the "patches welcome" response. A distribution cannot invite contributions, but then treat contributors with hostility when they arrive.

Moreover, in Arch's case it hardens the anti-signing camp into a position where it denies the reality of the package-tampering threat. You can already see this in some of the responses to IgnorantGuru and the bug reports he filed: commenters minimizing the statistical likelihood of an attack as grounds for not adopting any package signing plan at all.

Perhaps there is no reason to read ill will into any of McRae or the other Arch developers' resistance to package signing; perhaps they only seem hostile in context. But even if that is the case, by preventing others' code from making it into Pacman and the package database, they are letting Arch Linux users remain sitting ducks, as well as driving them away. It's hard to see how either result improves the project.

[Update: Arch Linux developer (and Pacman lead) Dan McGee strongly disagrees with this article, and has written about it on his blog. Additional comments can be found on our note about his posting as well.]

(Thanks to Roger Leigh for the heads-up on this topic).

Comments (42 posted)

Brief items

Security quotes of the week

So, here's the question: have I broken the law by using NoScript? I've used it for years, and it seems pretty ridiculous to claim that I now need to specifically go and whitelist the NYTimes just because it wants to hit me with an incredibly porous paywall. But, technically, I could see how an argument could be made that merely using NoScript makes me a DMCA violator by "circumventing" technical protection measures. Does this also mean that NoScript -- an incredibly useful tool -- has suddenly become a "circumvention device" overnight, because the NYTimes programmed an incredibly stupid paywall in javascript?
-- Mike Masnick

The best way for online social networking to become safer, more flexible, and more innovative is to distribute the ability and authority to the world's users and developers, whose various needs and imaginations can do far more than what any single company could achieve.
-- Richard Esguerra

Comments (4 posted)

Using SELinux and iptables Together (

Over at, Red Hat's Daniel J. Walsh digs into making SELinux and iptables play nicely together. It's a rather technical look at generating rules for iptables and writing SELinux policies to support the following use case: "I finally came upon a couple of use cases where I could write some simple rules and policy to further secure my laptop. I wanted to write policy to prevent all confined domains that are started at boot (system domains) from talking to the external network, and allow all domains started by my login process (user domains) to talk to both the internal and external networks. The idea here is I do not want processes like avahi, or sssd, or sshd or any other process that gets started at boot to be listening or affected by packets from an untrusted network. I want processes started by my login, like Firefox or my VPN to be able to talk to the network. If my vpn is shut down the system domains are off the network, while I can still use the Internet for browsing and email."

Comments (1 posted)

Fraudulent SSL certificates in the wild

The just-released Firefox update announcement includes the note that "Firefox 3.6.16 and Firefox 3.5.18 blacklist a few invalid HTTPS certificates." Mozilla's separate release on the subject is rather terse, but it does at least use the word "fraudulent" instead of "invalid." Much more information can be found in the Tor blog. "Last week, a smoking gun came into sight: A Certification Authority appeared to be compromised in some capacity, and the attacker issued themselves valid HTTPS certificates for high-value web sites. With these certificates, the attacker could impersonate the identities of the victim web sites or other related systems, probably undetectably for the majority of users on the internet." There is still quite a bit of uncertainty about what happened, but updating seems like a good thing to do regardless.

Comments (17 posted)

New vulnerabilities

aaa_base: arbitrary command execution

Package(s):aaa_base CVE #(s):CVE-2011-0468
Created:March 22, 2011 Updated:April 1, 2011
Description: From the openSUSE advisory:

shell meta characters in file names could cause interactive shells to execute arbitrary commands when performing tab expansion.

SUSE SUSE-SR:2011:005 hplip, perl, subversion, t1lib, bind, tomcat5, tomcat6, avahi, gimp, aaa_base, build, libtiff, krb5, nbd, clamav, aaa_base, flash-player, pango, openssl, subversion, postgresql, logwatch, libxml2, quagga, fuse, util-linux 2011-04-01
openSUSE openSUSE-SU-2011:0207-1 aaa_base 2011-03-22

Comments (none posted)

libvirt: arbitrary code execution

Package(s):libvirt CVE #(s):CVE-2011-1146
Created:March 18, 2011 Updated:August 4, 2011
Description: From the CVE entry:

libvirt.c in the API in Red Hat libvirt 0.8.8 does not properly restrict operations in a read-only connection, which allows remote attackers to cause a denial of service (host OS crash) or possibly execute arbitrary code via a (1) virNodeDeviceDettach, (2) virNodeDeviceReset, (3) virDomainRevertToSnapshot, (4) virDomainSnapshotDelete, (5) virNodeDeviceReAttach, or (6) virConnectDomainXMLToNative call, a different vulnerability than CVE-2008-5086.

Gentoo 201202-07 libvirt 2012-02-27
Pardus 2011-102 libvirt 2011-08-04
openSUSE openSUSE-SU-2011:0578-1 xen 2011-06-01
openSUSE openSUSE-SU-2011:0580-1 xen 2011-06-01
SUSE SUSE-SR:2011:007 NetworkManager, OpenOffice_org, apache2-slms, dbus-1-glib, dhcp/dhcpcd/dhcp6, freetype2, kbd, krb5, libcgroup, libmodplug, libvirt, mailman, moonlight-plugin, nbd, openldap2, pure-ftpd, python-feedparser, rsyslog, telepathy-gabble, wireshark 2011-04-19
openSUSE openSUSE-SU-2011:0311-1 libvirt 2011-04-07
Ubuntu USN-1094-1 libvirt 2011-03-29
Red Hat RHSA-2011:0391-01 libvirt 2011-03-28
Debian DSA-2194-1 libvirt 2011-03-18
CentOS CESA-2011:0391 libvirt 2011-04-28

Comments (none posted)

maradns: denial of service

Package(s):maradns CVE #(s):CVE-2011-0520
Created:March 21, 2011 Updated:November 21, 2011
Description: From the Debian advisory:

Witold Baryluk discovered that MaraDNS, a simple security-focused Domain Name Service server, may overflow an internal buffer when handling requests with a large number of labels, causing a server crash and the consequent denial of service.

Gentoo 201111-06 maradns 2011-11-20
Debian DSA-2196-1 maradns 2011-03-19

Comments (none posted)

Mozilla products and Chromium: fraudulent SSL certificates

Package(s):firefox thunderbird seamonkey chromium CVE #(s):
Created:March 23, 2011 Updated:May 2, 2011
Description: Mozilla and others have released new versions of their web browser-related packages in response to some fraudulent SSL certificates being exploited on the net.
Fedora FEDORA-2011-5161 seamonkey 2011-04-10
Fedora FEDORA-2011-5152 seamonkey 2011-04-10
Fedora FEDORA-2011-4250 nss 2011-03-28
CentOS CESA-2011:0373 firefox 2011-04-14
Mandriva MDVSA-2011:074 qt4 2011-04-12
Fedora FEDORA-2011-4244 nss 2011-03-28
Mandriva MDVSA-2011:072 gwenhywfar 2011-04-08
Ubuntu USN-1106-1 nss 2011-04-06
Mandriva MDVSA-2011:068 firefox 2011-04-07
Pardus 2011-61 firefox xulrunner 2011-03-30
Slackware SSA:2011-086-02 firefox 2011-03-28
Slackware SSA:2011-086-01 seamonkey 2011-03-28
Debian DSA-2203-1 nss 2011-03-26
Ubuntu USN-1091-1 firefox, firefox-{3.0,3.5}, xulrunner-1.9.2 2011-03-25
openSUSE openSUSE-SU-403 mozilla-xulrunner191 2011-03-25
Fedora FEDORA-2011-3946 galeon 2011-03-23
Fedora FEDORA-2011-3917 galeon 2011-03-23
Fedora FEDORA-2011-3946 gnome-python2-extras 2011-03-23
Fedora FEDORA-2011-3917 gnome-python2-extras 2011-03-23
Fedora FEDORA-2011-3946 perl-Gtk2-MozEmbed 2011-03-23
Fedora FEDORA-2011-3917 perl-Gtk2-MozEmbed 2011-03-23
Fedora FEDORA-2011-3946 mozvoikko 2011-03-23
Fedora FEDORA-2011-3917 mozvoikko 2011-03-23
Fedora FEDORA-2011-3946 gnome-web-photo 2011-03-23
Fedora FEDORA-2011-3917 gnome-web-photo 2011-03-23
Fedora FEDORA-2011-3946 xulrunner 2011-03-23
Fedora FEDORA-2011-3917 xulrunner 2011-03-23
Fedora FEDORA-2011-3946 firefox 2011-03-23
Fedora FEDORA-2011-3917 firefox 2011-03-23
Debian DSA-2200-1 iceweasel 2011-03-23
Debian DSA-2199-1 iceape 2011-03-23
CentOS CESA-2011:0375 seamonkey 2011-03-23
CentOS CESA-2011:0374 thunderbird 2011-03-23
CentOS CESA-2011:0373 firefox 2011-03-23
Red Hat RHSA-2011:0374-01 thunderbird 2011-03-22
Red Hat RHSA-2011:0375-01 seamonkey 2011-03-22
Red Hat RHSA-2011:0373-01 firefox 2011-03-22
CentOS CESA-2011:0472 nss 2011-04-29
CentOS CESA-2011:0472 nss 2011-04-29
Red Hat RHSA-2011:0472-01 nss 2011-04-28

Comments (none posted)

php: multiple vulnerabilities

Package(s):php CVE #(s):CVE-2011-0421 CVE-2011-1092 CVE-2011-1153 CVE-2011-1464 CVE-2011-1466 CVE-2011-1467 CVE-2011-1468 CVE-2011-1469 CVE-2011-1470 CVE-2011-1471
Created:March 23, 2011 Updated:April 13, 2012
Description: PHP contains a number of vulnerabilities, including denial of service via an empty ZIP archive (CVE-2011-0421), denial of service and information disclosure (CVE-2011-1092), code execution via multiple format string vulnerabilities in the phar extension (CVE-2011-1153), denial of service in strval() (CVE-2011-1464), denial of service via an "unspecified vulnerability" (CVE-2011-1467), denial of service via memory leaks in the openssl extension (CVE-2011-1468), and two other ZIP-related denial of service issues (CVE-2011-1470, CVE-2011-1471).
SUSE SUSE-SU-2013:1351-1 PHP5 2013-08-16
Oracle ELSA-2012-1046 php 2012-06-30
SUSE SUSE-SU-2012:0496-1 PHP5 2012-04-12
openSUSE openSUSE-SU-2012:0426-1 php5 2012-03-29
Debian DSA-2408-1 php5 2012-02-13
Scientific Linux SL-php-20120130 php 2012-01-30
Oracle ELSA-2012-0071 php 2012-01-31
CentOS CESA-2012:0071 php 2012-01-30
Red Hat RHSA-2012:0071-01 php 2012-01-30
Scientific Linux SL-php-20120119 php 2012-01-19
Oracle ELSA-2012-0033 php 2012-01-18
CentOS CESA-2012:0033 php 2012-01-18
Red Hat RHSA-2012:0033-01 php 2012-01-18
Oracle ELSA-2011-1423 php53/php 2011-11-03
Oracle ELSA-2011-1423 php53/php 2011-11-03
Scientific Linux SL-NotF-20111102 php53/php 2011-11-02
CentOS CESA-2011:1423 php53 2011-11-03
Red Hat RHSA-2011:1423-01 php53/php 2011-11-02
Gentoo 201110-06 php 2011-10-10
Slackware SSA:2011-210-01 libpng 2011-08-01
Debian DSA-2266-1 php5 2011-06-29
openSUSE openSUSE-SU-2011:0645-1 php5 2011-06-16
Ubuntu USN-1126-1 php5 2011-04-29
Pardus 2011-63 mod_php php-cli php-common 2011-04-07
Fedora FEDORA-2011-3666 maniadrive 2011-03-19
Fedora FEDORA-2011-3636 maniadrive 2011-03-19
Fedora FEDORA-2011-3666 php-eaccelerator 2011-03-19
Fedora FEDORA-2011-3636 php-eaccelerator 2011-03-19
Fedora FEDORA-2011-3666 php 2011-03-19
Fedora FEDORA-2011-3636 php 2011-03-19
SUSE SUSE-SR:2011:009 mailman, openssl, tgt, rsync, vsftpd, libzip1/libzip-devel, otrs, libtiff, kdelibs4, libwebkit, libpython2_6-1_0, perl, pure-ftpd, collectd, vino, aaa_base, exim 2011-05-17
Mandriva MDVSA-2011:052 php 2011-03-23
Mandriva MDVSA-2011:053 php 2011-03-23
Mandriva MDVSA-2011:099 libzip 2011-05-24
openSUSE openSUSE-SU-2011:0449-1 libzip 2011-05-06
Ubuntu USN-1126-2 php5 2011-05-05

Comments (none posted)

policycoreutils: privilege escalation

Package(s):policycoreutils CVE #(s):CVE-2011-1011
Created:March 21, 2011 Updated:April 5, 2011
Description: From the CVE entry:

The seunshare_mount function in sandbox/seunshare.c in seunshare in certain Red Hat packages of policycoreutils 2.0.83 and earlier in Red Hat Enterprise Linux (RHEL) 6 and earlier, and Fedora 14 and earlier, mounts a new directory on top of /tmp without assigning root ownership and the sticky bit to this new directory, which allows local users to replace or delete arbitrary /tmp files, and consequently cause a denial of service or possibly gain privileges, by running a setuid application that relies on /tmp, as demonstrated by the ksu application.

Red Hat RHSA-2011:0414-01 policycoreutils 2011-04-04
Fedora FEDORA-2011-3043 policycoreutils 2011-03-10

Comments (none posted)

quagga: denial of service

Package(s):quagga CVE #(s):CVE-2010-1674 CVE-2010-1675
Created:March 22, 2011 Updated:September 14, 2012
Description: From the Debian advisory:

It has been discovered that the Quagga routing daemon contains two denial-of-service vulnerabilities in its BGP implementation:

CVE-2010-1674: A crafted Extended Communities attribute triggers a null pointer dereference which causes the BGP daemon to crash. The crafted attributes are not propagated by the Internet core, so only explicitly configured direct peers are able to exploit this vulnerability in typical configurations.

CVE-2010-1675: The BGP daemon resets BGP sessions when it encounters malformed AS_PATHLIMIT attributes, introducing a distributed BGP session reset vulnerability which disrupts packet forwarding. Such malformed attributes are propagated by the Internet core, and exploitation of this vulnerability is not restricted to directly configured BGP peers.

Scientific Linux SL-quag-20120913 quagga 2012-09-13
Oracle ELSA-2012-1259 quagga 2012-09-13
Oracle ELSA-2012-1258 quagga 2012-09-13
CentOS CESA-2012:1258 quagga 2012-09-12
Red Hat RHSA-2012:1258-01 quagga 2012-09-12
Gentoo 201202-02 quagga 2012-02-21
SUSE SUSE-SU-2011:1316-1 quagga 2011-12-12
Fedora FEDORA-2011-3916 quagga 2011-03-23
Fedora FEDORA-2011-3922 quagga 2011-03-23
SUSE SUSE-SR:2011:006 apache2-mod_php5/php5, cobbler, evince, gdm, kdelibs4, otrs, quagga 2011-04-05
openSUSE openSUSE-SU-2011:0274-2 quagga 2011-04-05
SUSE SUSE-SR:2011:005 hplip, perl, subversion, t1lib, bind, tomcat5, tomcat6, avahi, gimp, aaa_base, build, libtiff, krb5, nbd, clamav, aaa_base, flash-player, pango, openssl, subversion, postgresql, logwatch, libxml2, quagga, fuse, util-linux 2011-04-01
openSUSE openSUSE-SU-2011:0274-1 quagga 2011-04-01
Mandriva MDVSA-2011:058 quagga 2011-04-01
Red Hat RHSA-2011:0406-01 quagga 2011-03-31
Ubuntu USN-1095-1 quagga 2011-03-29
Debian DSA-2197-1 quagga 2011-03-21

Comments (none posted)

tex-common: shell code execution

Package(s):tex-common CVE #(s):CVE-2011-1400
Created:March 23, 2011 Updated:April 5, 2011
Description: The tex-common script collection contains an insecure setting for the shell_escape_commands directive. As a result, it may be possible to execute arbitrary commands via a malicious .tex file.
Ubuntu USN-1103-1 tex-common 2011-04-04
Debian DSA-2198-1 tex-common 2011-03-22

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>

Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds