You are not logged in.
Pages: 1
Hi, i was just wondering if and when archlinux is planing to start signing packages?
There is a significant security risk with unsigned packages as anyone owning a mirror could just inject a package that contains malicious code and start having their way with a bunch of the archlinux community.
Think of the worst case scenario:
Someone hacks rsync.archlinux.org and injects a patched version of openssh. When people starts to update their systems they'll get the new package and most will probably not even question the update as it's just openssh which everyone knows is safe. Now, the users restart their opensshd and it starts broadcasts the machines ip address and users that has logged in with username and passwords in plain text every now and then to some random hijacked chinese server. After this a number of things can happen... I bet many of you can figure some of them out.
All this because the package wasn't properly signed.
I saw that when ftp.gigabit.nu mhakali was on the subject too and said that it should be the next thing on your todo list. It seems to me thou that it hasn't been.
The question I ask is probably more like: Will it be on your todo list or do you have a very good reason not to do it?
Swedish Archlinux Mirror Administrator - ftp.gigabit.nu
Offline
Offline
Offline
I was talking to neotuli about this a few weeks ago.
I have also been signing the packages I create, using a signing only subkey...
more info
Unfortunately, pacman doesn't support signature verification at this time, so it is a bit more work for someone to verify that the package did indeed come from me.
I like Mikael's idea about signing the md5sum list.. maybe it would be a good time to move to using sha1sum too...if they decide to go the signing route.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
maybe it would be a good time to move to using sha1sum too...if they decide to go the signing route.
This has been mentioned a few times. Here's the thing people don't get: archlinux does not use md5sums as a security mechanism. md5sums are NOT a security measure, and were never intended as such. They are there _only_ to verify that what you downloaded is what the server said you should download. It is a test for corruption, not safety.
I have been milling around using signed packages myself. If you want this done, please provide a patch, as I deem package signing as a lower priority than you guys probably do (I fully believe in "trusting the sender" implicitly - if you don't trust a mirror, don't use it).
Offline
phrakture. I *do* get it.
md5sums are indeed not used as a security measure in arch packaging.
The fact that collisions *can* occur, and have been show to occur, *could* cause an instance where a bit has been flipped (corruption) though drive failure, and the md5 would still match. It must be made clear that this is such an incredibly remote a possibility that it really isn't worth mentioning when discussing integrity verification alone. I think a migration to sha only makes sense, insofar as people have started migrating to sha *because* of the security side...so the tools and libraries are starting to be more focused on sha usage.
collisions when used in signing, however, *are* important for cryptographic strength. But phrakture is not talking about cryptographic strength, only non-corruption verification. As I noted above, md5 is still usable in that domain (very much so), but people are migrating away from it because of the cryptographic domain, and it is nice to have the same set of tools (and libs) work for many purposes.
That is all.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
I'd like to see signed packages. It is the "right way" to have trusted packages. It's all about making sure the person behind the server you trust really did send the package.
Offline
The fact that collisions *can* occur, and have been show to occur
Actually, on a technical note, collisions have only been shown to occur on file formats which accept arbitrary "hidden sections" or padding (or something like that). tar.gz files cannot accept any sort of padding of that nature, and thus it requires much more work to find a collision...
Regardless, the new pacman3 codebase supports both md5 and sha1 in pacman, and rather arbitrary integrity checks in makepkg itself (sha512sums if you want).
In fact, I think if pacman finds both set in the metadata, it validates against both, so it's a simple matter of adding it (again, this is supported by pacman3).
The real issue here is signing packages. Like I said, I don't consider this high priority. This is personal preference. If someone were to provide a patch to support key signing as well as a scheme for distributing official public keys, I will gladly discuss it / integrate it.
Offline
This probably doesn't help much, but thought I'd post anyways...
If you start signing packages, this can be used with metalink. or if you might use aria2...it doesn't support it yet, but maybe if you think this would be useful for Arch it might become a priority.
Here's the feature request: PGP signature verification from Metalinks
Here's how they're included in metalinks:
<verification>
<hash>443c265b57e87eadc0c677c3acc37e20</hash>
<signature>
</verification>
or
<verification>
<signature>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: See http://www.kernel.org/signature.html for info
iD8DBQBElLc9yGugalF9Dw4RAsplAJ9Vhjp8IgkMBdGdiYygXtYBcKZ6GwCffyTu
+gY8wsoFmSdAU6UiqakOcyo=
=hcew
-----END PGP SIGNATURE-----
</signature>
</verification>
PS - looks like the forum strips out type="pgp" whether I use CODE or not. Anyways, you get the idea.
Simpler/Faster downloads with error recovery - http://www.metalinker.org/
Offline
Pages: 1