Arch’s Dirty Little Not-So-Secret
igurublog.wordpress.com/2011/02/19/archs-dirt...Posted Feb 28, 2011, 7:57 PM UTC
5757
igurublog.wordpress.com
Users on the Arch Linux forum were contentiously divided on this issue, to the point where it became impossible to discuss it there. No one likes to have their vulnerabilities pointed out, which leads to denial and anger. While some saw the importance of it, and have been discussing it on and off for months, others reacted with bizarre fury that it was being discussed. Finally the moderators closed the thread and tucked it away in a section of the forum that only subscribers can access. I have seen this behavior before on the Arch forums – it is not a very open forum for discussing anything even slightly contentious. But hiding and censoring important security discussion was a new low even for them. As a result, many Arch users will simply not be exposed to the fact that their distribution has a major security problem.
He's wrong.
There have been plenty of discussions on the topic both on the forum and the mailing list. The problem is related to the package architecture and the "proper" way to do the signing in a KISS model, coupled with the sheer manpower necessary to make it happen once it's decided on. Threads on the forum get closed for bringing up the a topic that's already been discussed a hundred times.
19
Yeah, I've been following the mailing list. While some exchanges have been a tad heated, the discussion has been pretty productive overall.
5
their need manpower? let's do this r/archlinux!
3
rolls up sleeves
3
Anonymous reddit is not your personal army.
-4
Until a cat is involved.
Put a cat in a bin, blame it on Arch's lack of package signing. Done.
14
not?
1
Patches welcome. Stop bitching and code it up.
17
On the one hand, I completely agree with you (which is why I don't bitch).
On the other, if there is a development roadmap at all to the Arch project, I think this particular issue should be prioritized very highly.
I use arch for personal use and love it. I do not personally have the time currently to contribute a patch for this issue, but this is a showstopper for me (and many others) to ever use Arch in anything but a dev environment.
13
In the meantime, I’m considering writing a script that will grab the db files containing the (unprotected) MD5 sums from several servers, compare them, and use them to check packages.
Even worse. Instead of helping with package signing coding he's going to write a kluge script. What a tremendous waste of time.
9
What are you talking about. His solution is perfect, everyone knows that MD5 is perfect. It's impenetrable.
5
No need for sarcasm. Whilst MD5 obviously isn't perfect, and certainly isn't a replacement for package signing, it's still better than nothing. In particular, the most computationally tractable MD5 vulnerability lets you create two files with the same MD5sum; whilst there are vulnerabilities related to creating a file with the same MD5sum as another file -- which is what you'd need to make a package that seems legit even after comparing its MD5sum to what it should be -- they're currently still pretty computationally difficult, AAUI.
(Also, it's not like the guy chose MD5. You work with what you have).
3
Wow ... if he put that much work into a blog post ... imagine the patch he could have written to implement package signing ...
2
[deleted]
0
It seems many of the primary Arch devs are against package signing, or at least are resistant to adding this code to the final releases. Thus even the small changes the developers above make tend to be held in limbo on git servers, never seeing real use. Meanwhile, the data on the mirrors sits completely vulnerable.
0
This is not new. The reason is and will always be the same: if you want it, code it. It's open source - please try to contribute more than just blather
12
Unlike many other situations where this argument comes up, this is much easier for core Arch developers to implement because they already understand all of the esoteric internals of the package system. They are the only people who do! It's not hard to implement package authentication, but it's hard for me to do it.
Instead of just doing it, they are waiting for some random person with unknown intentions to come along and 'submit a patch' for this highly sensitive security feature.
2
Sadly, it's actually NOT true that it's a simple task. It's a very complicated task. Not to sound offensive, but if you don't understand the programming work involved, please don't assume it's a simple task. It's easy to solve it in a shitty manner, but fairly hard to solve in a good, clean manner
1
For the other side of the story: http://www.toofishes.net/blog/real-story-behind-arch-linux-package-signing/
8
I must admit, I was not aware of this issue. I have been using Arch as my primary OS for the better part of 5 years. Granted, I'm watching neither the mail list nor the forums. However, this issue is fairly important to me. I have played with Fedora off and on for the past couple of years. Fedora 14 was generally acceptable to me as far as stability and usability is concerned. Maybe it's time to fully make the switch.
What's particularly disturbing to me is not the lack of package signing. It's the lack of interest in correcting the issue. The reason I didn't look into the issue is because I figured "why wouldn't the packages be signed? it's a modern distribution. Who doesn't sign their packages these days?"
I love Arch, the KISS philosophy, and the ability to make my distro work the way I want it to. However, security issues as big as this getting pushed aside make me... nervous.
5
Funny, i've been using Arch for a few years and decided to start looking at other OS'. I put Fedora on my test machine last night. My only complaint so far is that it installs TOO MUCH. Although having my iphone tether right out of the box (and not fighting the ipheth-pair mess) is pretty nice.
Now to rip out the gnome, httpd, cups, networkmanager, language, other crap it installs.
2
Yeah, they definitely install more than you might like. But overall it's a solid system.
As far as getting it to install less, have you looked at the respins?
2
I haven't yet. Got one in mind? I'm trying out crunchbang right now, since it already runs OpenBox. When i tried switching Fedora to OpenBox and removing all GNOME packages, it pretty much crapped itself.
1
I use gnome, personally. Though I have used the KDE respin in the past and found it very complete.
i've heard great things about crunchbang.
1
Can we just fix this so people stop bitching about it? Seriously, the complaining is more annoying (to me, anyway) than the threat.
5
[deleted]
1
My personal apathy.
1
Lack of signing doesn't bother me. I use Arch on a personal laptop and for a very simple server at home that runs rtorrent and xbmc. I also do some development in it at work on occasion, but my work computer also has Windows 7 which is where I spend most of my time.
I really have very little reason to be concerned with this. In fact, the only scenario I can see this being a serious security issue is if a company's IT wanted to roll with Arch for production, or maybe if a major site wanted to be hosted on Arch. But my understanding is Arch and its developers have never pretended that those are Arch's "demographic". I think the bleeding edge nature of Arch and its occasional "instability" rule out using Arch for any serious production situation anyway.
4
Arch's lead dev, Allan, said it best:
‘I think I know every distribution using pacman as a package manager and (unless there is an enterprise level distro I am missing) if peoples lives depend on one of these distros, then I am sorry to say it but in my opinion they are stupid and deserve to die.’
http://mailman.archlinux.org/pipermail/pacman-dev/2011-February/012483.html
I don't think Arch's devs made any pretense that their distro was supposed to be the end all, be all. Neither is their goal to publish a distro that will rocket up distrowatch's charts. It is nice distro to tinker with, that's it. If one desires to use it on a production machine, then he needs his head examined.
5
[deleted]
3
if anybody's playing it down, it's because it's already been thoroughly discussed and all the people complaining about it aren't willing to do any work for it.
11
I don't like its lack of repository security.. but I like Archlinux :( ..both the system and the philosophy.
I guess I will keep using it on my home computer, but definitely not on my server. And when people ask me about it, I'll warn them it's not a good system for servers :(
1
The developers' attitude toward security is quite off-putting. From what I've read, it's always been "in the works" but their condescending comments are unsettling.
3
Might have to do with arch being more single-user, hobbyist oriented than production server oriented.
4
I've used Arch for quite a few years. Regardless of what it's oriented for, basic-level security is a must in any respectable OS.
7
Get asked the same question countless times for years with the answer easily accessible on Wikis and sticked forum FAQs and see how long you keep a friendly attitude.
1
Maybe because it should have been fixed long ago?
1
Says you. The developers apparently have a different opinion, and honestly don't care whether you use Arch or not.
They've given their responses and explanations on this issue over and over. I don't blame them for being rude to people who still don't get it.
1
Which gives off the warm fuzzies. If they don't care about their project enough to maintain security or care whether others use the distro, why should anyone else care for it?
1
[deleted]
1
Can someone explain to me what the problem here is? If the signatures are on the same server, they can be compromised at the same time the package is. If the signatures are on a different server, compromising the signature server or even DDOSing it could halt updates completely. If the local network is compromised and a false server is provided to your update system, regardless of where the signatures are, they can still be falsified. If I'm understanding correctly, the point of signatures is to reduced the scope of threat, but a lot of this article at the beginning seems to be explaining threats that don't make much sense to me.
2
A proper solution would probably use something like PGP/GPG. As long as the private keys are not compromised and you have a copy of the public key, you can verify a package's integrity.
http://en.wikipedia.org/wiki/Pretty_Good_Privacy
If i get a week off anytime soon, I plan on seeing how far I could get with a pacman patchset. I'm not familiar with the work already done, but I would probably be looking at a gpgme based solution.
8
Alright that makes more sense to me. I am used to seeing just simple md5 hashes of the package being used as the signature. I study lots of crypto (or used to) in my free time, and now it makes way more sense to me. If the package maintainers have private keys, or if the distribution maintainer has private keys to sign package hashes or entire packages where the public key can be used to recover the package, that is a way better solution which withstands the problems of ddos'ing a package hash server and individual package modifications on mirrors.
I'm not sure how other distros do it, but I can see how RSA signed packages where the package manager for the distro can verify the integrity is a great solution. Thanks, have an upboat =).
Edit: also, props for wanting to integrate a gpgme solution into pacman and actually working towards it. I'm not an arch user (slackware), but that is a badass solution to secure package management.
2
That is what we had started on ages ago, and it is now in master in a still to-be-finished form. Help is always welcome! http://projects.archlinux.org/pacman.git/log/
1
I believe they're currently working on it (I've read something about this a few days ago, can't remember where).
1
Here's the pacman-dev archive txt for February. It is being worked on :)
There's also still an open flyspray for this.
5
Or you could just make your own packages and be your own repository.
THE ARCH WAY.
-3
No, you simply told the author, in more or less words, to use Gentoo.
4
Personally, I take responsibility for packages installed on my system. Over years using Windows and a variety of GNU/Linux distros I have found that signed or authenticated doesn't mean functional and/or non-destructive.
Due to the rolling release nature of Arch, you're welcome to hold back on updates until they've been used by others for a while and not reported as bad... if you don't have a dev environment to test in, or don't want to install new updates directly onto whatever machine you're working on.
-9
That's not the problem though. The problem is that anyone who has access to any of the mirrors for the official repositories could change code, and you wouldn't know. Of course just because it's not signed in general doesn't necessarily mean anything, but you now have the problem of trusting the security for each mirror, there is nothing client side to tell whether a package is compromised or not.
6
my testing tells if the package is compromised... if it fails due to bad implementation, or malicious changes, then it doesn't go into my system
-14
I hope you're trolling.
6
Might it be that the reason this hasn't changed, yet, is that those who care enough about this issue don't want to use Arch (including develop for it) until it is fixed for fear of the risk, while those who already are using Arch have already accepted the risk and are more concerned with other development?
That might be the reason, but it does Arch no good to have people turned away from using Arch for this reason.
Part of my point was to let people make the inference that without certain minimum security requirements already being met, the attitude of "then do it yourself" (while good in many other ways), introduces a sort of selection bias against people who would do security development for Arch.