Security issue regaring unsigned packages, how to solve it [outdated]

pablokal · 2011-03-01 08:06:27

This issue is out of date now as pacman 4 in now out which solves this issue.

So for the sake of people how want to go into this piece of history:
How to solve it by using paccheck

Please inform your self on this topic below and take action.
I propose paccheck to be put as default in archbang.

Install: packer -S paccheck
Use: first synchronize mirrors: sudo pacman -Sy
Then: paccheck --install abc xyz

This will install package abc and xyz and their dependencies, check only those targets (including full mirror compare if configured), and offer to install them. Be sure to read the report to determine if installation is indicated.

How to do a general update with paccheck

The system update procedure with paccheck is:

paccheck

# then, if you're comfortable with paccheck's report:
sudo pacman -Su

When run with no options, paccheck runs "pacman -Sy" (update your database) and "sudo pacman -w --noconfirm -Su" (downloads needed updates but installs nothing). It then checks the files and gives you a report. Nothing is installed. You can even suppress the pacman download if you want with a command line option, but do so with care - paccheck needs the packages downloaded to check them.

Edit, End of August 2011: Watch out for pacman version 4 when the pacakage signing issue will be solved and paccheck will be superfluous.
In the 2011.09 version paccheck is installed by default.

Why, the discussion about why package signing is important
In this post: http://igurublog.wordpress.com/2011/02/ … so-secret/
the importance of package signing is clearly explained.

And the lack of security of the present mirrors: http://igurublog.wordpress.com/2011/02/ … or-mirror/
Also the hubris and the smugness with which some devs are negating the seriousness of the problem. This issue seems to be first noticed in 2006 and still no solution.

I think this is the core weakness of Arch, that there is an unofficial hierarchy between devs. Some leadership and decision making is above criticism. Especially when there has to be dealt with serious matters the emotions and all sort of weird social processes take over straight problem solving.

So a post on the arch forum https://bbs.archlinux.org/viewtopic.php?pid=897884 is moved to Topics going nowhere.
I think this is a slap in the face for all critical users and discourages people to put into center stage or on the table what has to have priority. This isn't a matter where you as user can write an app to solve it
although is has been done with paccheck: http://igurublog.wordpress.com/download … -paccheck/
but a lot of users will miss the discussion and the urgency of it and won't use it.

Edit: with pacman 3.5.1 you will have to use an updated version from AUR: http://aur.archlinux.org/packages.php?ID=46763

A new attempt is made to discuss this topic on the Arch Forum; it offers a very detailed and clear clarification of the problem: https://bbs.archlinux.org/viewtopic.php?id=115137

Reaction of Allan to this post:

I will repeat my offer. If anyone provides patches for the remaining issues with pacman as given on this page: https://wiki.archlinux.org/index.php/Us … ge_Signing , then I will get all the patches in a format suitable for actual merging to the pacman code base. I made this offer several weeks ago on pacman-dev and quite a few people said they had patches that were "almost ready". As usual, none ever eventuated...
Now as to whether this is really important... well, it is... but:
1) the described ARP attacks require the hacker be on your network. That is not a particularly practical attack for most Arch usages (home computer...).
2) exploited mirrors are likely to be detected quickly. Even faster now paccheck has been provided. But they would have been detected by people who segment their downloads across mirrors anyway (or even downloaded packages from a different mirror than their database) and there are a lot of people who did that.
3) if it was that important, people would have the motivation to actually code on it...
The quickest way (in fact, probably the only way) to get this fixed is to provide the patches for pacman. Having the feature implemented there will likely increase the motivation to get signing used in the repos.

Argument 1: I understand that this assumption is debatable. Some argue it is possible to do this outside the local network.
Argument 3: Circular argumentation: The subtext of all posts of the mods on the Arch forum on this is that it is really not important. It is the domineering opinion that it is not. It will be even considered unloyal if you think different about it and start mobilizing people to do something about it. Even mentioning it, is considered out of the boundaries and the thread is again moved to dustbin.
Maybe the only way to take it serious and getting people to code, would be for Allan to declare it a serious problem. His position is dualistic. Fact is that most linux distro's see this as a necessary safety precaution. Here you can read more on the kind of attacks that unsigned package managers are especially vulnerable to: http://www.cs.arizona.edu/stork/package … tacks.html

Another attempt by IgnorantGuru:
http://igurublog.wordpress.com/2011/03/ … n-subject/
The fact he got banned, is tmho graceless and a big shame.

Last edited by pablokal (2011-03-01 08:51:08)

lrcaballero · 2011-03-01 11:27:16

Thank You very much Pablokal...

Cheers

pablokal · 2011-03-01 15:42:52

It is interesting how the post on this subject evolved: https://bbs.archlinux.org/viewtopic.php?pid=898057.
Some citations

Search the forums and you will see there is some solution coming "really soon now" - since years tongue.
*The roof is leaking...really serious
#Yeah, I know, it has been leaking for years.
*But it is really starting to rot now.
#We have contacted a contractor and he said time and time again that he would come and fix it.
*So, he is not fixing it is it. We should find some one else to do it.
#Why don't you go live somewhere else if you don't like it here.
*But I care about the house.
#You're spoiling my day. Get lost.

I wrote this particular post in this thread, because the post was moved to Topics Going Nowhere.
The reactions went then very negative and could be compared to a public beating:
For instance B wrote:

I firmly suggest you stop your campaigning, even though it's not as obnoxious as ignorantguru's, it's still irritating. You have been asked before, by other moderators, not to turn other threads into another package signing thread. And you're doing it again.
(I don't know where this is about -P.)
If you want it, quit sitting around and whining, and get to coding. This is not Ubuntu.
I repeat: This Is Not Ubuntu.
Are we clear?

Note the "we".

So when you 're concerned about some valid criticism that is being uttered and want to discuss it, the topic is being killed because it is coming back and back again, because the problem doesn't get solved since 2006 it seems. This means it won't be solved soon or the coming year.

Edit>
I wrote B to ask about the package signing bit and he admitted that he had mistaken me for someone else and adapted his post to a much more moderate one.
So the irritation speaking from this former post is probably aimed at that other person too.
After this I thought about deleting this post , but I think it is informative about the Arch forum. > end edit>

To put a problem of this kind back on your own lap, (it is not Ubuntu, start coding yourself) when you're throwing up a problem of this magnitude, is just plain childish, I think.
I would like your view on this. Am I wrong or blunt? Or did I touch a open wound? I would like to be corrected if that is necessary.
I think it is important to work in egalitarian and open spirit, cooperative with the possibility to criticize each other but also with respect of different opinions and feelings. Maybe this is also a sign that the group of capable coders is just not big enough or won't get their differences sorted.

Last edited by pablokal (2011-03-01 17:27:30)

mycorunner · 2011-03-07 13:11:11

I'm glad that I found this thread. I'm relatively new to Arch but when I read that article I thought it was worthy of posting. I searched the Forums but didn't find the above linked thread, maybe because it was moved to TGN. Anyway, my thread was immediately closed.

It seems to me there should be a sticky or at least coherent, ongoing discussion on the topic. It was troubling that I couldn't find any threads that had anything to do with the topic newer than 2008.

I'll check out paccheck, and I'm going to have to do some more reading so I can figure out how this security hole affects me, considering I'm still fuzzy on how this all works.

pablokal · 2011-03-10 14:29:03

I made this thread sticky so it will be found more easily by new users.

mycorunner · 2011-03-11 10:47:23

Thanks

There's a way better attitude here than over on the Arch forums.

pablokal · 2011-03-15 14:29:03

A new attempt is made today to discuss this topic on the Arch Forum: https://bbs.archlinux.org/viewtopic.php?id=115137

Here is it:

Hi all. Recently I was looking for a new Linux distribution to jump ship to, since I don't like the direction my current distro is going, and I came across Arch. I installed it in a VM to try it out, it seemed great and I was almost ready to make the switch when I found out that you guys don't do package signing. Or package list signing. I did a little research on the forums here and from what I can tell not a lot of people realize how big an issue this is. So I did a little write-up explaining just how easy this makes compromising an Arch system, and published it on some security related boards as well. If this post gets any attention at all, I'm sure it won't be all positive. My hope, however, is that this post might push the issue a little further and get more people interested in making package signing a reality for pacman. Here's the write-up:

0wning Arch: Why Package Signing Is Important

Arch Linux is a popular linux distribution aimed at power users. It allows a great deal of customization, providing a minimal core system from which the user can build off of. Arch is normally a security conscious distribution, with a rolling release system and simple tutorials on the wiki outlining how to enable full disk encryption and switch Linux password hashing from md5 to sha512. However, the Arch Linux package manager, pacman, seems to be an exception to this general security consciousness. This is because pacman uses neither a signed package list nor signed packages when upgrading or installing new software. The only check pacman makes on the integrity of a software package is that the package's md5 checksum matches the checksum listed for that package in the package list. This makes exploiting an Arch system almost trivial provided an attacker is able to place themselves between the Arch system and the Arch package repository. For those unfamiliar with why package signing is so important to the security of a Linux system, I will outline the simple steps an attacker would have to take to gain root privileges on an Arch system using only this flaw in pacman. To be clear, unless you completely trust every network you've ever updated your Arch system on, you've potentially been 0wned.

Subverting an Arch Package:

Making alterations to an Arch package (at least well enough for pacman not to throw up errors) is EXTREMELY simple. I was lazy and simply opened my chosen package (gzip) up in file-roller and editted the ".INSTALL" file. I chose to alter the gzip package because it's in the core repository which virtually everyone will be using, it's a very small package, its functionality almost never changes (it's nearly 20 years old), and it already contains a ".INSTALL" file to alter.

In the ".INSTALL" file I added a single line to the end of the "post_install()" function, which was "mkdir /U_HAVE_BEEN_0WNED". This just creates a directory at the filesystem root called "U_HAVE_BEEN_0WNED", but I could just have easily told the script to run wget and grab some malicious script or have created another user or uploaded /etc/shadow and/or any ssh keys to myself. Or I could have run "rm -rf /" if I just wanted to watch the world burn. The command runs as root so the options are pretty much limitless. I also changed the package version number in the filename and ".PKGINFO" file (from 1.4-2 to 1.4-3 in my case) so that it would be seen by pacman as a newer version and offer to upgrade.

At this point astute observers are probably saying "Wait, since you altered the package, the md5 checksum of the package no longer matches the package list. Won't pacman ignore it?"

Yes. Which is why we're also going to alter the package list, which isn't signed either. Again, this is a trivial process. I just downloaded the core.db.tar.gz file, opened it up in file-roller (because, again, I'm lazy) changed into the gzip directory and altered the "desc" file so that the FILENAME, VERSION and MD5SUM parameters matched my modified package.

Mirroring Evil:

The next step to 0wning an Arch box with no known vulnerabilities (other than pacman and the human behind the keyboard) is to set up a mirror to host the modified package list and package(s). I used vsftpd, making sure anonymous downloads were enabled. The Arch mirror directory structure is simple enough; package lists and packages sit in the same folder, which uses the naming structure "archlinux/{core|community|extra}/os/{i686|x86_64}/" depending on which repository is being requested. Place the packages and package lists in the i686 or x86_64 directories, depending on your architecture, and you're done.

Again, astute observers will notice that at this point we need to get the target Arch system to use our mirror. Why would they do that? Naturally, any security conscious person wouldn't do that. So we're going to trick the machine into thinking that WE ARE their usual mirror.

Playing Monkey-In-The-Middle:

At this point, we need to get the target Arch machine to connect to a network that we either control (using a rogue access point, for example) or that we can perform ARP cache poisoning on. At this point, ettercap is your best friend. I won't go over its usage here, that'd take much too long. I will simply say that once we've poisoned their ARP cache, we're going to perform a DNS spoofing attack and impersonate the package mirror our target Arch machine uses. At this point, all we do is wait for them to check for system upgrades. Running "pacman -Syu" will download our altered package list and show our altered package(s) as available upgrades. Upon upgrading, the user will see nothing out of the ordinary, there is no indication that any packages were untrusted or anything like that. They've been 0wned, and they are none the wiser.

Fixing the Problem:

In the long term, the only real fix is to implement proper signing for both packages and the package list. However, security can be greatly improved right now by simply signing the package list. This would eliminate the ability of attackers to fake an update when one is not available, and would require an attacker to craft a malicious package with an identical md5 checksum to the legitimate package it seeks to impersonate. So, as previously stated, the obvious first step is to begin signing the package list as soon as possible. Once this is accomplished, signing for all packages should also be implemented.

Q & A:

Q: Why would you write this? Doesn't this put Arch users at risk now that anybody can find out how to compromise an Arch machine?
A: This flaw has been known to Arch and pacman developers since at least 2006, possibly earlier. It's been 5 years. It's time for a proper fix. Hopefully this will push things in the right direction.

Q: So if Arch switches to a better hashing algorithm than MD5, will that fix the problem?
A: No. This vulnerability has nothing to do with the strength of MD5. Packages using SHA512 checksums would be equally vulnerable. The problem is proper signing of packages and, most importantly, the package list.

Q: What can Arch users do to keep themselves safe in the meantime?
A: Only download packages from trusted mirrors over trusted networks. A tool like paccheck may be useful, but only if the attacker hasn't dns spoofed all the mirrors, which is entirely possible and not difficult to implement.

Q: If this flaw has been known for 5 years, why hasn't it been fixed?
A: I can only assume it hasn't been fixed due to lack of developer resources, interest, and knowledge of how big a problem this actually is.

IgnorantGuru · 2011-03-16 10:55:03

Good to see this being discussed here openly without being hustled out of sight like on the Arch Forums. Thanks for spreading the word on it pablokal. A few points not covered above...

you can let it go on; it will go on with pacman -Su ; when you see warnings you have to stop the update manually; fastest way is to close terminal window.

This is actually incorrect - paccheck will never issue "pacman -Su". You must do this manually. The system update procedure with paccheck is:

paccheck

# then, if you're comfortable with paccheck's report:
sudo pacman -Su

When run with no options, paccheck runs "pacman -Sy" (update your database) and "sudo pacman -w --noconfirm -Su" (downloads needed updates but installs nothing). It then checks the files and gives you a report. Nothing is installed. You can even suppress the pacman download if you want with a command line option, but do so with care - paccheck needs the packages downloaded to check them.

In the case of "paccheck --install PACKAGELIST", which is used to first check then add selected packages from a repo, it will run "sudo pacman -w --noconfirm -S PACKAGELIST" to download the packages, but not install them. It then does a check and asks you if you want to proceed with installation.

As stated above, this is paccheck's official site and there is a forum thread.

Regarding the discussion:

It is often said by the Arch developers that this is a huge project and the coders aren't doing it. I submitted two flysprays that could hugely improve Arch's security in this area with virtually no work needing to be done. It turns out that one of these ideas - to have the server sign the database - was submitted by one of their own developers 3 years ago. It was shot down at that time because pacman package signing was 'almost complete'. He is still an Arch developer and offered to implement it immediately when he saw my request, but there is no one willing to authorize the simple change required. With the use of a simple signature checking script which I offered to write, this change would make 150+ mirrors as secure as the primary Arch server. The other idea - to include SHA256 sums in the database - would make paccheck's job more thorough without the need for full mirror compare. I even provided a simple patch for their script. Yet they simply refuse to include it for no known reason. You can see and vote on these here and here. They are very effective interim solutions which will improve your security substantially while the pacman devs wrestle with their full-blown package signing (for how many more years no one knows).

As for Allan's claim that no one is coding, that is probably because the developers are disgruntled that he refuses to include code they submit. He seems to be the primary stopping point for why this isn't getting done, as far as I could discern. It's discouraging to write code only to have it ignored.

So there seems to be an unwillingness to address this, which is obvious from the 5+ years this has been on the table. It's simply not that difficult, and there is no valid technical or manpower reason why this can't be vastly improved within 24 hours.

Beyond this, the Arch forums censor the information about the issue. If they feel the issue is simply repeated, why do they not close the threads if they deem that necessary, but leave at least a few in place so people can become aware of the issue? I think they are embarassed by it, but it is irresponsible to hide it. IMO users have the right to be informed of this issue, which impacts their security as much as any other root exploit.

The idea that mirror compromise will just 'be noticed' before anyone is affected is wishful thinking. There are over 150 Arch mirrors, some run on very insecure platforms.

Here is a real life example of a compromised Linux mirror, which wasn't discovered for almost one year. It's also worth reviewing Sourceforge's recent attack. It's not directly related to Arch, but this statement:

Sourceforge.net has been around a long time, and security decisions made a decade ago are now being reassessed. In most cases past decisions were made around the general principle that we trust open source developers to work together, play nice, and generally do the right thing. Services were rolled out based on widespread trust for the developer community. And that philosophy served us well.
But in the years since then, we've evolved from hundreds of sf.net users to millions, and in many cases it's time to re-asses the balance between widespread trust and security.

reminds me of Arch. It has grown considerably, but they have not updated their security in many years. Sourceforge learned their lesson the hard way.

Lack of signing is a very serious security flaw in Arch which can be exploited fairly easily at any time. paccheck helps, so I do recommend using it. Also, please communicate to the devs that this issue is important, and spread the word - at the very least users should be informed so they can evaluate it and address it for their themselves. Thanks.

mycorunner · 2011-03-16 16:06:22

Because this thread has been stickied, perhaps it would be beneficial to add a summary of the issue in the first post. It could be something like a simple explanation of the problem (minus any discussion/criticism of the developers, so it won't get closed) and a simple how-to for paccheck or any other stopgap solutions.

I'm wondering, is paccheck q complete solution? Does it essentially fix the issue with pacman?

IgnorantGuru · 2011-03-16 16:56:55

mycorunner wrote:

I'm wondering, is paccheck q complete solution? Does it essentially fix the issue with pacman?

As the author, I'll give you my opinion, but I don't mean to curtail others opinions.

paccheck is basically statistical in nature. It can compare the database on as many mirrors as you configure, and can even do byte-for-byte compares on all the packages on as many mirrors as you configure (to combat fraudulent packages designed with MD5 collisions). It is a question of time/bandwidth vs security - the more mirrors you use, the lower the chances of installing compromised packages. With enough Tier 1 mirrors it is very effective. If one or several mirrors are compromised, it is unlikely that many or all would be simultaneously affected. Personally, I think using 3 or 4 database mirrors and one full compare mirror is sufficient for high security. Stick to Tier 1 mirrors or Tier 2 mirrors that use different upstreams - as explained in the paccheck page.

However, the core issue with pacman is that the developers are not signing their packages. If the primary Arch server (not open to public use) is compromised, paccheck will not detect this, since all the mirrors will agree. That level of security can only be obtained by the packagers signing the packages, or at least the database for some improvement. Also, if the devs would add SHA256 sums to the database, even without signing, this would alleviate the need for paccheck's high-bandwidth compare function (MD5 being a compromised hash). So paccheck is about the best we can do with what the Arch developers are giving us, but it is not as complete as a distro signing their product and updates.

Hope that clarifies what it does. Feel free to inquire if anything is unclear on this.

Last edited by IgnorantGuru (2011-03-16 16:58:15)

IgnorantGuru · 2011-03-16 18:12:52

Also, I just noticed that I have been banned from the Arch Forums for this post (not sure if it was deleted or just dust-binned), so please note that I can't respond in the paccheck thread there to any issues, and I won't receive notifications of new replies - you can bring them here or to my blog. Thanks.

pablokal · 2011-03-17 06:31:35

IG, I would like to stick up for you on the Arch forum. But it would mean an immediate ban.
As I have already been warned.
It is awful to be confronted with these kind of policies.
In real life I was active in many groups and saw many bad things happen, so weird group behaviour isn't new for me. I'm really thinking about about moving to another distro because of the immature Arch community.
Will have to be a rolling release though.
Lets hope some other people will stick out their neck for you.
But my hopes aren't high.

IgnorantGuru · 2011-03-17 08:11:58

I appreciate that pablokal, but don't get yourself banned on my account - they won't budge anyway, not very democratic or open to feedback on their policies. I just felt like telling them what's what - I don't really care about their ban.

I like the rolling release model too.

encyclomundi · 2011-03-21 13:57:32

Thanks for continuing to surface this important issue. I really like the FLOSS community overall and Archbang in particular. I'm dismayed at the politics that gets in the way of wider adoption and usage of Arch in particular and FLOSS in general.

I started my own Wiki http://encyclomundi.org precisely because of "deletionist" elements on Wikipedia.

Anyone is welcome to post articles around these issues there if they like. Also about any projects or passions you are working on as well.

pablokal · 2011-03-21 15:29:42

Thanks, E, for your support and success with your wiki!

oliver · 2011-03-24 17:18:34

looks like something is happening in archland wrt package signing

https://wiki.archlinux.org/index.php/Us … ge_Signing

lrcaballero · 2011-03-24 22:48:24

FYI ArchBangers! check this out too oliver...

http://planet.archlinux.org/

oliver · 2011-03-25 07:06:10

lrcaballero wrote:

FYI ArchBangers! check this out too oliver...
http://planet.archlinux.org/

very interesting read... thanks for posting

pablokal · 2011-03-25 09:01:43

looks like something is happening in archland wrt package signing
https://wiki.archlinux.org/index.php/Us … ge_Signing

This page was already there a month or two ago .
I can't recognize real fundamental progress here.

@Irca: thanks for the link: http://planet.archlinux.org/
But it deserves some comment.
First it wouldn't have been written if this article wasn't written as the writer admits himself:
http://lwn.net/SubscriberLink/434990/4c611307c60a7ae1/
So it is really in defence of that. IG 's position in the Arch community was hopeless as he had been totally demonized.
The way this happened seems to be not problem to the loyal Arch users and that makes me feel I don't want to belong to that community
But with this article the reputation of Arch rightfully came at stake, because the way IG was treated was taken into account.
Now to the way Dan McGee defends what has happened, shows the same intrinsic weakness as Allans.
They only accept solutions in the way they see it fit and accept no temporary but rather effective solutions as put forward by IG. IG made it clear that he didn't want to go into the requirements that were put forward regarding patches for pacman, but to say a proposition is not code is childish as IG put forward a method he could provide and assist in. If help is offered and you won't take it because you want it do it only in your own way, this doesn't make the help useless or the intent of it suspicious. IG honestly stated this was the only way he could do it.

What is kept out of the defence is the censorship and misuse of power on the Arch forum. This is accepted as normal, it seems.
The fact that new users aren't warned by default by the wiki in the Beginnersguide and distro's compared
https://wiki.archlinux.org/index.php/Ar … tributions
I only found it on the FAQ amidst clearly kind of mockery arguments: Q) Why would I not want to use Arch?
-you require package signing for security.
No link or explanation provided to get a hunch on what this is about.

If you read the comments of Dans supporters on the site where he originally published it:
http://www.toofishes.net/blog/real-stor … e-signing/ .
you get really sick of the tone and aggression that is behind it.
If you're not an uncritical fan, you don't deserve Arch.
If you utter any criticism, you are an enemy.

pablokal · 2011-05-19 12:58:16

This was on the Wiki for half a day or so on the beginnersguide page on the top, where it should be:

Then is was removed; vigilant conduct of the Arch community ready to spot every threat, my compliments!!

The link clickable: http://lwn.net/Articles/434990/

ArchVortex · 2011-08-06 20:14:54

The latest from Allan McRae [http://allanmcrae.com/2011/08/pacman-pa … -repo-add/]

pablokal · 2011-08-08 14:58:48

Thanks for pointing that out! Hope it, the pacman update, will be in time for the new AB release.

ArchVortex · 2011-08-21 22:29:35

The second part, this time about Pacman Key http://allanmcrae.com/2011/08/pacman-pa … acman-key/

Added:

Allan wrote:

Once you have some keys in your keyring, you can manipulate them using pacman-key and some standard gnupg flags including --edit-key, --export, --list-{keys,sigs}, etc. The --edit-key option is fairly important as it allows you to do things like adjust the trust levels or locally sign keys in the keyring, which builds our web of trust.

It's important to me having control or the option to adjust the trust levels and key signing. It appears Arch is getting this package signing finally right. Better late than never I guess.

Last edited by ArchVortex (2011-08-21 23:02:17)

ArchVortex · 2011-08-29 00:19:41

And the last part: http://allanmcrae.com/2011/08/pacman-pa … -3-pacman/

pablokal · 2011-08-29 13:11:25

We'll have to wait a little bit more:

This will all be available in the upcoming pacman-4.0.0 release. There is already and RC1 release out for testing, but an RC2 will be made "soon" and it is probably worth holding out for this given the number of changes made.

Great that this issue will be solved in the very near future!!

Bra1n0v3rfl0w · 2011-09-20 15:06:59

Hi all,

I'm sorry if it will be a little long, so Thanks for your time.

All started after leaving FreeBSD due to a problem without solution regarding a linux software I must use for work, that can't run on linux compat, & some minor unsolved problems.

So searched a Linux distro, and found Arch (seemed perfect to tweak for my needs/taste), then downloaded Arch Linux, and to see it installed downloaded ArchBang too. Perfect.
Please WiLL X TrEmE don't hate me, You did a Great work, but i prefered Arch mainly to really learn it (and then tweak it to my bad taste).

I also printed all wiki pages to study it!!

Now that I've quite finished my tweak, reading about Kernel breach, I found on IG blog his complaint regarding not signed packages, so I read all posts on Arch forum, and discoverd this one too: Thanks IgnorantGuru ! Thanks Pablokal !

I have to say that this is really bad cause it damage only Arch Linux, ArchBang, CTKArch, and all users, and no one else.

Now I opened the Faq I printed and the note regarding package signing was not present (Faq updated 9 Feb 2011). I'm Really Disappointed !

And also: archserver is going to close (maybe is it related?)

Anyway I'm afraid that the kernel.org breach did something worse we don't konw: Why kernel.org, linux.com, linuxfoundation.org servers are still down? I Hope to be Wrong!

Note that also Frugalware been hacked (14 September news), from their site:
Important server in the Frugalware infrastructure was compromised: http://frugalware.org/
and: http://article.gmane.org/gmane.linux.fr … devel/9899

And what about Arch mirrors (and/or main servers) with unsigned packages?? Are we safe??

Note: I'm not going to post this on Arch forum to be offended and not receive an answear or a serious opinion.

Sorry Again to bother You, and Thanks for Your Time.

All the best to ArchBangers & ArchBang !!

Mat

ArchVortex · 2011-09-20 21:31:57

Mat,

Starting with pacman 4.0, pacman will handle all the package signing. Pacman 4 is in the testing repo right now. Please read the above posts I've made which contain Allan McRae's posts on pacman and package signing/security. Pacman 4.0 should be released soon.

pablokal · 2011-09-21 07:03:21

This version comes with paccheck, which you can use as a temporarily solution.
If you don't trust it that way, I recommend temporarily stop using arch and install aptosid for instance.

Bra1n0v3rfl0w · 2011-09-21 15:28:20

Thanks for the hints.

But the release date of pacman 4 is not known. I hope it will be as soon as possible.
Regarding aptosid I don't like it much; don't take me wrong it's a good distro, but I prefer minimal install (CLI only) with BSD init style, and then build the system as I like (eg: no login manager, no DE, no KDE, twm as WM...and so on).

I think I will wait for new pacman 4. Thanks again & many compliments for good work You both are doing. My best wishes.

Ped · 2011-09-29 10:31:54

My hart truly goes with the developers who are working on this. I wish there was something I could do to help, but at the moment I just do not consist of the expertise. I'll pray that they'll implement this thoroughly and that arch will benefit from a mindset change and a new way of looking at things. MAY IT GO WELL!! to all those involved!!

Arch Linux

Announcement

#1 2011-03-01 08:06:27

Security issue regaring unsigned packages, how to solve it [outdated]

#2 2011-03-01 11:27:16

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#3 2011-03-01 15:42:52

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#4 2011-03-07 13:11:11

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#5 2011-03-10 14:29:03

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#6 2011-03-11 10:47:23

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#7 2011-03-15 14:29:03

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#8 2011-03-16 10:55:03

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#9 2011-03-16 16:06:22

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#10 2011-03-16 16:56:55

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#11 2011-03-16 18:12:52

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#12 2011-03-17 06:31:35

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#13 2011-03-17 08:11:58

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#14 2011-03-21 13:57:32

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#15 2011-03-21 15:29:42

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#16 2011-03-24 17:18:34

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#17 2011-03-24 22:48:24

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#18 2011-03-25 07:06:10

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#19 2011-03-25 09:01:43

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#20 2011-05-19 12:58:16

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#21 2011-08-06 20:14:54

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#22 2011-08-08 14:58:48

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#23 2011-08-21 22:29:35

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#24 2011-08-29 00:19:41

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#25 2011-08-29 13:11:25

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#26 2011-09-20 15:06:59

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#27 2011-09-20 21:31:57

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#28 2011-09-21 07:03:21

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#29 2011-09-21 15:28:20

Re: Security issue regaring unsigned packages, how to solve it [outdated]

#30 2011-09-29 10:31:54

Re: Security issue regaring unsigned packages, how to solve it [outdated]

Board footer