Arch Linux

Or just sign the package lists with checksums distributed. :) Gah why didn't I think of that from the beginning. Ahwell.

I'd and some others had some similar and related thoughts and discussions in the following bugzilla feature request.

http://bugs.archlinux.org/task/4633

http://bugs.archlinux.org/task/4633#comment9788

Ok, here are some thoughts about how this could be done :


Someone gets gpg keys for archlinux.org 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 archlinux.org 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 archlinux.org 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 : http://bbs.archlinux.org/viewtopic.php?id=35609 , post #7

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?

Yeah, as always patches and code would help - everyone knows this is a good idea, but we all have other priorities

The algorithm is simple, just after getting
ftp://ftp.archlinux.org/core/os/i686/core.db.tar.gz
You need to download a
ftp://ftp.archlinux.org/core/os/i686/core.db.tar.gz.asc 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://archlinux.org/GPG-KEY | 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.

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 archlinux.org
it comes with issues if the mirrors are will out of sync. but in my mind it works ;)

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.

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: http://gcarrier.koon.fr/2008/06/03/packages-signing-in-pacman-archlinux-getting-secured/ looks like finally something is happening.

If this was implemented, would it be required -- or just optional for users who want more security?

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.

Yes, but right now we've got no repository signing at all. It might be too drastic of a change.

?!
what do you mean "too drastic"? where do you expect to appear problems with that?

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.

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.

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.

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?

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.

here's some of the GPG work that I can find:

http://code.toofishes.net/cgit/dan/pacman.git/log/?h=gpg
http://code.toofishes.net/cgit/dan/pacman.git/log/?h=gpg-more
http://code.toofishes.net/cgit/dan/pacman.git/log/?h=gpg-tools

http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=gpg

Dan, do you happen to have any links or pointers to answer the "why this isn't merged" question?

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.

Any update on this ? What is left to do exactly ?

Check the archives of the pacman-dev mailing list.

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!

CHASM, the Cryptographic Hash Algorithm Secured Mirroring solution
https://korg.wiki.kernel.org/index.php/Gsoc2010:ideas
http://projects.robescriva.com/projects/show/chasm

It's something at least!

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?

Take a look at http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg ... work has been under way for quite some time.

Can't we just start to automatically sign ftp://ftp.archlinux.org/core/os/i686/*.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. :-)

This is important, this is not a theoretical threat, there are tools to attack unsigned updates, and the bad guys use them. For example: http://www.infobytesec.com/down/isr-evilgrade-Readme.txt

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.

can somebody tell me the status of this bug? WONTFIX or pending by somebody?

According to http://mailman.archlinux.org/pipermail/arch-dev-public/2011-November/022067.html 51% of our packages are signed.

Can we close this now?

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...

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

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.

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.

SigLevel = PackageRequired

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