Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.

FS#5331 - Signed packages

Attached to Project: Pacman
Opened by Mikael (mhakali) - Friday, 01 September 2006, 11:08 GMT
Last edited by Dan McGee (toofishes) - Saturday, 11 February 2012, 21:52 GMT
Task Type Feature Request
Category Backend/Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Medium
Priority High
Reported Version 0.7.2 Gimmick
Due in Version 4.0.0
Due Date Undecided
Percent Complete 100%
Votes 166
Private No



I have noticed that the single most vulnerable point of archlinux (assuming you trust the developers) is that any mirror can be hacked and injected with various packages, and there would be virtually no way for an end user to notice this. As pacman would accept the local list of packages and the package downloaded/installed. And if someone noticed it it'd be too late either case.

This also means that users need to have some sort of trust to the mirror of their chosing. Many wouldn't even consider it probably. Others would trust their gut feeling. Or use the (almost terribly slow, for us sweedes)

As I just set up my new public archlinux mirror it hit me that there is not any way that I can genuinly garuntee my users that my packages are safe and unmodified, more than users doing sample tests now and then. (If you need a pretty fast Swedish mirror, read at :)).

Signed packages would solve these problems. The signatures can be verified by a public key which the developers intergrate so any package going up for publishing will need a signature. The signatures can preferably be stored in the resperatory database file (current.db.tgz etc) and verified by pacman upon install.

If a user choose to trust other developers than the main they should be able to add their public keys to pacman's database aswell. pacman -Ka /home/data/, or smthing.

Now here comes the best part; the code is already fully developed :) Intergration with gnupg will assure this kind of verification to be easily in to place.

Hit me back with comments and/or suggestions.
This task depends upon

Closed by  Dan McGee (toofishes)
Saturday, 11 February 2012, 21:52 GMT
Reason for closing:  Implemented
Comment by Mikael (mhakali) - Sunday, 10 September 2006, 19:46 GMT
Or just sign the package lists with checksums distributed. :) Gah why didn't I think of that from the beginning. Ahwell.
Comment by Anonymous Submitter - Friday, 23 March 2007, 23:49 GMT
I'd and some others had some similar and related thoughts and discussions in the following bugzilla feature request.
Comment by Lone_Wolf (Lone_Wolf) - Friday, 27 July 2007, 09:16 GMT
Ok, here are some thoughts about how this could be done :

Someone gets gpg keys for and community , possible the other arch sites also.(should be the person who is owner of the domain, probably judd)
Devs and TUs get personal gpg keys.
The keys are registered with a free certificate authority like CAcert
(Aside from the pgp signing this will also allow https for the registered sites and such)
see also CAcert on wikipedia

The CAcert root certificate and public arch/dev/tu keys are published on for download with instructions to put them in a specific place.
(could be put in a separate package also, not sure if that's a good idea)

makepkg gets a new array with 2 options :
sign=(arch personal)

binary packages that have sign=(personal) will be signed locally with the personal key by makepkg, before upload.
In the repos the sign=() values for packages need to be added to the repo-db.

After uploading the repo maintenance software for current/extra/testing/unstable/community checks for sign=(arch) and signs all marked packages with the archlinux private key.

Immediately after downloading pacman checks the db for sign values and controls if the packages are signed correctly.

Note 1
it may be a good idea to get separate gpg keys for and community

Note 2
this doesn't need to be done all at once, there could be several stages.
It would probably be a good idea if this was organized as a project lead by an arch-developer.

Note 3
Also posted on forum : , post #7
Comment by Jonas Wagner (veers) - Saturday, 22 September 2007, 17:02 GMT
I would really like to see this because I think it's a serious security issue. Very basically everyone that can do a man in the middle attack between you and the mirror can own your box. I think the easiest way to fix this would be to get the *.db.tar.gz files over a TLS encrypted link. But that would cause some unnecessary load on the mirrors and would not protect you against manipulations on the mirror. So I'm all in for the signature approach. Is there any way for me to help to solve this issue?
Comment by Aaron Griffin (phrakture) - Monday, 24 September 2007, 02:01 GMT
Yeah, as always patches and code would help - everyone knows this is a good idea, but we all have other priorities
Comment by Damjan Georgievski (damjan) - Wednesday, 13 February 2008, 14:17 GMT
The algorithm is simple, just after getting
You need to download a file

and then just
gpg --verify core.db.tar.gz.asc core.db.tar.gz
if the exit status is not 0, the core.db.tar.gz is not to be trusted and should be discarded.

The package database file contains the MD5 checksums of the packages so it covers changing packages too.

The only this is need for a little setup on the user part, ie.:
wget -O - httpS:// | gpg --import

So the patches and code are not the main issue I think...
The question is if the ArchLinux maintainers are ready for a more strict security policy! Obviously the private gpg key must be strongly guarded, and there should be a process of puting packages in the repos.
Comment by Raeven K. Bathory (kumico) - Tuesday, 26 February 2008, 18:23 GMT
in the mean time,
you could always create a little script to handle downloads(that calls wget, etc. does it itself...)
make that the xfer* in pacman.conf
this script would check the fiel type being requested, and if t's a db.tar.gz,
and download it from
it comes with issues if the mirrors are will out of sync. but in my mind it works ;)
Comment by Nicolai Lissner (blackpenguin) - Saturday, 16 August 2008, 11:37 GMT
signing of core.db.tar.gz wouldn't be enough if pacman doesn't honour the %CSIZE% since it is very easy to fake md5sums if filesize doesn't matter.
Comment by Jonas Wagner (veers) - Saturday, 16 August 2008, 15:05 GMT
That's true. But md5 shouldn't be used for authenticity checking anyway. It's ok as a checksum tough to check for random errors. If we use gpg signatures this shouldn't be a problem. Regarding this bug, this blog post might be of interest as well: looks like finally something is happening.
Comment by Matthew Bauer (matthewbauer) - Sunday, 07 March 2010, 02:28 GMT
If this was implemented, would it be required -- or just optional for users who want more security?
Comment by Anonymous Submitter - Monday, 08 March 2010, 00:43 GMT
I think it should be required. People inherently trust (and have to trust) the integrity of their OS. Anything that can increase and maintain that integrity is a good thing IMHO.
Comment by Matthew Bauer (matthewbauer) - Monday, 08 March 2010, 02:03 GMT
Yes, but right now we've got no repository signing at all. It might be too drastic of a change.
Comment by Nicolai Lissner (blackpenguin) - Monday, 08 March 2010, 15:04 GMT
what do you mean "too drastic"? where do you expect to appear problems with that?
Comment by Mikael (mhakali) - Monday, 08 March 2010, 15:47 GMT
Heh. Only 3,5 years gone by. ;)

I just don't see how a distro in modern day can condole the trust of individual mirrors.

We have a mirror with about ~10k unique (archlinux) users. Injecting a backdoored package would probably go unnoticed. Or for the manner if someone hacks it. How can you as (seemingly being) users motivate this risk? This btw goes for any mirror of course.

mathewbauer: You will need to sign at a central place where the packages are released. Signatures per mirror will not move the place of trust. It should be mandatory and implemented per default. But of course users could just ignore the signatures with a custom pacman. Or a spacial parameter to pacman.

Just my few cents.

Btw; if you look for some distro signing packages you should look closer at RPM / DEB based ones. Mainly Ubuntu, Debian, RedHat, CentOS, OpenSuSE, SuSE, Mandrake and family. There's plenty of flexbility in forks of them. And the package manager actually *scales* for a growing package number. Where as pacman imho don't.
Comment by Daniel Roethlisberger (roe) - Monday, 22 March 2010, 15:00 GMT
Package metadata signing should be implemented and signature verification
enabled by default. I don't consider this to be just some low-priority
wishlist item, only "nice to have" -- the failure to provide integrity
verification of downloaded packages / meta-data directly affects the
security of all Arch installations out there and certainly rules out Arch
for any kind of serious, real-life purposes.
Comment by Aaron Griffin (phrakture) - Tuesday, 23 March 2010, 20:07 GMT
Stop adding useless information to this bug report please. If you want it implemented, click the "vote" button.

If you're not providing any forward motion here, you're just being irritating. One more "me too" comment isn't going to help.

Open source software is what it is because of contributors - not because of people voicing their silly little opinions.
Comment by Daniel Roethlisberger (roe) - Tuesday, 23 March 2010, 21:34 GMT
I apologize for my choice of words, I didn't mean to offend anybody
and I really appreciate all the hard volunteer work that has been
put into Arch and pacman in particular.

I'd really like to see package signing becoming a reality, and I
don't think that a flameware will help achieving this.

Could anyone shed some light on the state of things, Dan perhaps?
What was the problem with the 2008 effort of Pierre Carrier? Is
all that's needed some good patches and a bit of testing or are
there fundamental problems on the conceptual level?
Comment by Dan McGee (toofishes) - Tuesday, 23 March 2010, 21:38 GMT
His effort wasn't lost, but I got zero effort once I pointed out things that needed to be fixed- I never got any resubmits. There were some fundamental issues but the ground has been laid for this stuff to work. If it was just testing, this would have been released 2 years ago, but I've yet to see people step forward and present working *code* solutions to some of the outstanding issues.

To everyone else on this bug- your comments simply dissuade those that want to work on this from getting things done because 1) they have to wade through your propaganda and 2) they will be too afraid to mess up. So please don't think you are helping. Honestly, Aaron and I care very little about making this distro popular, so we aren't looking to ride the happy train to the Distrowatch #1 spot here. So if you think your threats of leaving the distro help, you're wrong.
Comment by Aaron Griffin (phrakture) - Tuesday, 23 March 2010, 21:50 GMT Comment by Allan McRae (Allan) - Tuesday, 23 March 2010, 22:36 GMT
In true Allan fashion, here is a possibly stupid suggestion...

How about we merge Dans gpg-tools and maybe gpg branches to pacman master. They are fairly finished sections of code and I think fairly set in how they are going to be (I have reviewed them at least twice in the past looking into this). After that, we would be able to sign packages/databases and pacman can read in those signatures. That would leave the verification and frontend to be done (started on gpg-more).

I think this would give visibility to what needs finished and maybe (unlikely...) encourage more contributors.
Comment by aze489 (aze489) - Friday, 23 July 2010, 02:54 GMT
Any update on this ? What is left to do exactly ?
Comment by Allan McRae (Allan) - Friday, 23 July 2010, 03:19 GMT
Check the archives of the pacman-dev mailing list.
Comment by B Haines (hainesb) - Sunday, 15 August 2010, 10:23 GMT
I tried Arch Linux a little over a year ago and must admit that I love this distro. I installed Arch in a VM (Sun.. now Oracle VirtualBox) because I did not want to use a distro that lacks signed packages as my main but I still wanted to try the distribution that I had read so many good things about. I loved everything about Arch except the lack of signed packages and SELinux. Now SELinux is easily (well, not too easily) resolved but this lack of signed packages is really amiss. In over a year there literally seems to be no accomplishments in the addition of signed packages for Arch Linux. I was really hoping to switch back to Arch today but will have to wait a little longer it seems. I will stick with Fedora in the meantime as my main and will give Gentoo a try as far as something similar to Arch goes (except with signed packages).

I do want to thank you for such an awesome distribution! I love pacman! I even liked it better than Yum! I have not had the opportunity to play with emerge (Gentoo) yet so I have no basis for comparison there. Honestly, there was so much that impressed me about Arch that I would not know where to begin. I am not posting this to criticize the lack of gain towards this endeavour in a negative manner. I just REALLY hope to see this, above anything else on the Arch plate, happen since this one missing feature completely eliminates Arch as an option for everyday use or as a main OS for the average user. Incidentally, a quick Google search will demonstrate that there would be a LOT more Arch users if this feature were implemented.

Oh, and regardless of what OS I am running at the time I will DEFINITELY be running Arch again as soon as this feature is implemented in a "moderately" secure manner. Thank you all for all of the hard work and for an awesome (perhaps the most awesome that I have ever used) Linux distribution! I really hope to use it again soon! Heck, I am tempted to install Arch again in the VM just for kicks! It really was that fun!

NOTE: I highly recommend that ANYONE who is considering trying Arch out do so! Even if you do not want to run it as your main still install it in a VM as you will definitely learn a lot about Linux in general that you did not know. And when you run in to trouble there is a ton of people on the Arch IRC channel ready and willing to assist! I mean it when I say that I love this distro!
Comment by B Haines (hainesb) - Thursday, 28 October 2010, 19:36 GMT
CHASM, the Cryptographic Hash Algorithm Secured Mirroring solution

It's something at least!
Comment by Mark (voidzero) - Sunday, 06 March 2011, 23:46 GMT
Package signing on archlinux. I've searched quite a number of pages that discuss this but it seems that people either 1) don't want it; 2) are aggressively refusing to implement it; 3) do want it but can't code it themselves (I fit into this category because I'm not a cryptographer); 4) refer people to old and obsolete posts (while this is frowned upon on the forums); and I'm sure that other people can add at least 4 more points.

Consider this my $0.02. I think there's some sort of curse on archlinux and package signing. There seems to be a lack of dedication. That's the problem in my view. So, an ultimatum *has* to be thrown into the equation, which is this: Should Archlinux implement package signing / package security, or should the idea be thrown into /dev/null?
Comment by Jens Adam (byte) - Monday, 07 March 2011, 09:47 GMT
Take a look at ... work has been under way for quite some time.
Comment by Tomas Mudrunka (harvie) - Sunday, 29 May 2011, 19:33 GMT
Can't we just start to automatically sign*.db.tar.gz (and begin use sha1 or larger sum in it instead of md5) each time it's updated? Once this will be done, we'll be able to implement the check somehow. Is it really so hard to add single file generated by gpg to ftp? It does not have to use 100% secure private key yet. Just to have something to use. Once pacman patch will be ready, somebody will make some secure keypair and deploy the public key to pacman and private key to primar repository.

It isn't really so hard to add some insecure "snake-oil" GPG signature to repository and provide public key.

I think this would be an act of good will and will encourage people to start working (and testing) on this issue seriously. :-)
Comment by jason barney (jasonx) - Saturday, 18 June 2011, 09:35 GMT
This is important, this is not a theoretical threat, there are tools to attack unsigned updates, and the bad guys use them. For example:

In the mean time, while updates are not secure, would be nice to at least be able to update through https instead of plain http or ftp.
Comment by Daniele C. (legolas558) - Sunday, 06 November 2011, 16:04 GMT
can somebody tell me the status of this bug? WONTFIX or pending by somebody?
Comment by Karol Błażewicz (karol) - Sunday, 06 November 2011, 16:12 GMT Comment by Sven-Hendrik Haase (Svenstaro) - Thursday, 19 January 2012, 17:55 GMT
Can we close this now?
Comment by Tomas Mudrunka (harvie) - Thursday, 19 January 2012, 18:40 GMT
Svenstaro: well... currently there is no automatic key distribution for archlinux, and some of packages are still not signed, but i guess it's not pacman issue. so i think we can...
Comment by Daniele C. (legolas558) - Tuesday, 14 February 2012, 09:36 GMT
In my opinion this is NOT fixed.

1. read the original bug submission
2. answer question: is this fixed?

Answer is no. We need no "philosophical" fixing, lease re-open
Comment by Dan McGee (toofishes) - Tuesday, 14 February 2012, 14:50 GMT
No, we will not be reopening this bug, that is ridiculous. The proper course of action is to open a new bug targeting a specific issue that you think is still lacking. Your last comment was merely inflammatory and really serves to just anger those that spent a lot of time and effort implementing on their own time what we do have, and pro tip #1: not every feature gets implemented as originally proposed.
Comment by Daniele C. (legolas558) - Wednesday, 15 February 2012, 10:18 GMT
Dan, I did not mean to flame or to not respect contributors.

I need to setup and maintain several systems and my concern is that under specific requirements I cannot use Arch Linux because "some" packages are unsigned, that's why I think it's not closed. I will carefully examine this bug report and eventually open another one if I can better define it.

Maybe I should investigate how to forcibly disable unsigned packages; thanks for your pro tip.
Comment by Allan McRae (Allan) - Wednesday, 15 February 2012, 10:21 GMT
SigLevel = PackageRequired

The is already a TODO list for Arch with the remaining unsigned packages on it so no need for another bug report.