You are not logged in.
there should be a way to get the keys through ssl to ensure that they have not been compromised.
Offline
SSL has been mostly broken.
Screaming obscenities since 1979.
Offline
I seriously wonder about the paranoia inherent in the assumption that YOUR machine is a good target. Anyone here gives their chairs a shake before sitting down, just in case?
Some paranoia is good, but for a personal machine where my main concern is that I don't lose data rather than my boring life is open to some no-life hacker or big conglomerate, I'd worry much more about having high-integrity backups than some possible loopholes allowing external parties access to my machine.
I agree getting hold of most of our personal pictures, mp3's, etc is not a huge cause for concern but many hackers want to use your machine to mask their own identities, send spam, hide illegal material, and other things you want no association with.
Offline
ngoonee wrote:I seriously wonder about the paranoia inherent in the assumption that YOUR machine is a good target. Anyone here gives their chairs a shake before sitting down, just in case?
Some paranoia is good, but for a personal machine where my main concern is that I don't lose data rather than my boring life is open to some no-life hacker or big conglomerate, I'd worry much more about having high-integrity backups than some possible loopholes allowing external parties access to my machine.
I agree getting hold of most of our personal pictures, mp3's, etc is not a huge cause for concern but many hackers want to use your machine to mask their own identities, send spam, hide illegal material, and other things you want no association with.
Indeed. There probably isn't anyone out there trying to get access to "ngoonee's computer" specifically, but getting access to computers in general is a goal.
I don't think anyone is planning to break into my house either, but I still lock the door and close the windows when I go out, just in case an opportunist happens to pass by.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
@ brianhanna and Xyne
I agree with both your statements, but that just shifts things one notch up, why should Arch be targetted for a botnet. Its not generally a server OS, though some servers do run it, nor is the general user-base as ignorant as to NOT notice out-going connections.
So, as Xyne says, we lock the doors and close the windows. Probably just set a good password and use iptables to block all incoming and stuff. We don't scrutinize the air vents in case there's a hole big enough for a pet monkey to squeeze through and grab your house keys....
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Alright I want to get something wrote of for the bounty. The main problem is that I am not very knowledgeable about the process of signing lol. Is basically seems the packages need to be signed with a key from maintainers and then verified by pacman. Here is my meager attempt so far, If people can please post up some more ideas for me I can do the actually writing up of the bounty.
Idea
The general idea would be to verify that all packages that are created by the maintainers maintain their data integrity throughout the process of being synced to mirrors and then onto our machines.Goal
Implement a system where the packages are cryptographically signed by trusted maintainer keys and then verified by pacman when they are downloaded by a user. The maintainers should either have a gpg ( is there something better?) key that they share or their own individual keys that they use to sign package once they are created. The public keys should be able to downloaded enmass from Arch. The keys will be downloaded and the packages will be compared against the key that was used to create the packages. On the users end the keys could be downloaded, compressed and stored in a common directory. When keys are changed or a new developer is created the package manager would have to be able to compare the keys on the local host to the keys on the main key server.
The easiest way to achieve the necessary security would to be use an existing PKI infrastructure, like SSL certificates.
A possible setup
Maintainers/devs ad the distro will need to have a public/private key pair.
Each repo gets a queue (hidden for public) called something like 'ready for distributrion'
Package creators sign pkg with their own personal certificate and place it in 'ready for distribution' , NOT directly in the repo.
A Repo coordinator (could be automated) then continues :
decrypt pkg using the creator's public key
encrypt with archlinux private key
place signed pkg in repo.
Users download the package, pacman decrypts it with the archlinux public key.
The archlinux and maintainers public keys will be downlodable/installable from archlinux.org , maybe through a https page.
To keep things simple, Pacman should treat the decryption as just another verification method (md5, sha1 etc) .
Tasks for the project :
1. Selection of a PKI infrastructure.
2. addd support for this PKI to pacman
3. adjust the repo software and setup the PKI infrastructure (might be better to seperate this ... )
I expect there will be a long transition period in which we will have both signed and unsigned pkg.
Once pacman has the PKI support, private repos can also use it.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Note that a start has been made on gpg package signing here: http://code.toofishes.net/cgit/dan/pacm … log/?h=gpg . It just needs motivated people to finish it... (hence the bounty to increase the motivation).
Offline
Alright, I am actually going to get in contact with Dan, and get a run down of what he is doing, and then write that up as the proposal. Thanks, all.
Offline
Alright, I am actually going to get in contact with Dan, and get a run down of what he is doing, and then write that up as the proposal. Thanks, all.
You can also join pacman-dev ML where all discussions are happening.
last dan's post about gpg :
http://mailman.archlinux.org/pipermail/ … 09965.html
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
Offline
I don't really have much to contribute to the development aspect of this thread, but package signing still doesn't remove every possibility of problems, right? Mozilla or Google could put CC number or password phishing into their browsers for Windows and most people wouldn't notice until it was too late. Forgive the bad example, but any software could be an issue. Even distros that use package signing have the potential problem of the original packager putting malicious code in it. I understand that package signing adds an extra layer of protection and eliminates the possibility of the mirror introducing the problem, but this entire thread brings up the interesting question of, "How can we trust any software we use?"
Offline
"How can we trust any software we use?"
That's one of the points of open source: since anyone can look at the source, it's hard to put malicious code without noone noticing.
Offline
Or rather, it's pointless to insert malicious code in open source, since if someone finds out you've been sneaking in code, you'll just get laughed at, and noone will use your software. But hey, maybe it's possible to really obfuscate the code, making it look like something useful, while doing something malicious as a side effect. Is there a case when someone has found malicious code in a serious open source program, actually?
Offline