Which I think is the devs point.
With a hypothetical isp and government, lets add a cert org in there as well, might as well the isp's are supposed to be involved, I can't see anything making it completely fool proof.
But from a wireless/lan and updating point of view this all makes sense.
Though you could quite easily argue why use a router thats not in your control, for security updating. This I'd of thought was a no no from a security point of view and should it be up to the arch devs to secure?
My opinion is my security is my problem would I personally use an insecure router to make updates nope.
Does this problem exist if we remove ISP collaboration or an insecure router is my question then I guess I've got something to fear?
The problem is not really to encrypt the datastream as much as it is just making sure no ones been hacking a mirror for example.
If you ask me I'd say the archlinux community got a HUGE security hole as anyone can provide with a mirror without any prior credentials. It's all fair seeing as free bandwidth is needed to keep this kind of project going but as archlinux grows atleast I think that you can afford to be abit picky.
It was mentioned earlier in this post that it should be alot of work to get a package that can inject harmful code into your system, but that's not really true.. there's a bunch of easy things to just call from pretty much any opensource package. Just build a new package with the nasty bit of code and edit the desc file for that package from the current.db.tar.gz files. Soon as you get a chance to upload it to any mirror and read the FTP logs you instantly got _alot_ to go on.. and that's just for taking over machines. How hard is it to implement like "rm -rf /" to be executed the next time X starts? All you need is less than a minute to get this new package up onto a mirror and your done.
Ofcourse it's hard to hack a machine and not any bozo can do it.. but what if say a mirror owner left a terminal logged onto the mirror by misstake and his really retarded friends thinks it would be funny to do this?
Oh well that's just my two cents.. but it does make you wonder if mirror owners can be trusted and if we should need to trust their friends/family/enemies and so on?
Wouldn't it be easier just to sign the packages or atleast the repo db to ensure that this won't happen?
Last edited by _nalle (2007-08-12 02:34:56)
Swedish Archlinux Mirror Administrator - ftp.gigabit.nu
I installed 64bit arch on my macbook a couple of days ago and am impressed by its smoothness, consistency & tweakability, great job. However after wondering which measures were taken to ensure package integrity I came across this topic with the stunning answer: none. I agree with _nalle, rbl et al that this is a gaping security whole, just a matter of time before bad things happen.
Hell, all major distributions have at least _some_ mechanism in place to prevent this. Slackware, OpenBSD, Gentoo, Debian, Ubuntu, RedHat, Novell, etc. And still, from reading this and the other posts linked here, the Arch Dev team seems to think of this as a non-issue?
There's allready an RSS feed notifying people of new updates so why not use that? Some simple, short & sweet extension to the XML and package integrity can be guaranteed ... just a thought.
<pubDate>Mon, 03 Sep 2007 14:03:30 -0000</pubDate>
<pkgSha512></pkgSha512> # SHA-512 hash of the package on the official mirror
<msgSign></msgSign> # GPG ascii signature of the text between [<title>] -> [</pkgSha512>]
Simple huh? The <msgSign> public key gets distrbuted in the ISO's. Should be posted somewhere on website and/or in signed e-mail in case of change. When a [security-aware] user sees an update on pacman s/he can do some trivial client-side python/perl/bash scripting to fetch the feeds message, check the integrity of the message with <msgSign> public key, check the SHA-512 hash of the downloaded tar.gz and .. done.
1. No change to the current pacman
2. No need for loads of gpg keys for all package maintainers
3. No change to current mirror architecture
4. No third parties involved. Just you and the person using the RSS-private key.
5. No annoyance for people who blindly trust the current system
For those wondering: yes, SHA-512 message digest is _secure_enough_. If for some reason not this could obviously be changed by another gpg signing but thatll make things unneccesary complicated. Mailing list could be used instead of RSS feed but the idea stays the same. Just some simple, basic scripting completly in agreement with ARCH philosophy I'd say