But what I meant is that some kind of tables showing which security features each packages managers support would have been interesting.
]]>BTW, slashdot coverage: http://it.slashdot.org/article.pl?sid=08/07/10/227220
]]>Hmm, nowhere in the article did it mention who funded this research. Gotta be M$. It brought up some good points but the study should do a compare and contract with Macs and Windows systems as well.
Highly unlikely anyone funded it. The report came from a research-oriented university. At research-oriented universities, this *is* what professors get paid to do. They spend 8 hours a weak on their classes (if that) and the rest on whatever research projects they're working on.
]]>Intrigued by the article I started looking now I stumbled across this, https://cesium.di.uminho.pt/pub/archlinux/ now I know being self signed means its not the best but better than not being signed at all.
But my question is it presently not possible to use this, would this require a major rewrite of packman?
I think that, primarily, additions would have to be made, I don't think much would have to be rewritten, and little to none rewritten from scratch.
]]>But my question is it presently not possible to use this, would this require a major rewrite of packman?
]]>It's nice to hear that signed packages are beeing worked on. But for the meantime I would propose additional sha1-checksums for each package, because md5 can no longer be considered secure enough. If two different hashes are applied, it's extremely difficult for an attacker to find a collision, which matches both hashes.
That's what package signing is for, to ensure authenticity. A hash without proof of origin is worthless, like toofishes points out.
MD5 is significantly faster in software than SHA's are. Since we only expect integrity confirmation from the hash, it wouldn't make sense to change it. If we wanted authenticity from it as well, there are a lot more (important) things to do than switch to one of the SHA's.
]]>It's nice to hear that signed packages are beeing worked on. But for the meantime I would propose additional sha1-checksums for each package, because md5 can no longer be considered secure enough. If two different hashes are applied, it's extremely difficult for an attacker to find a collision, which matches both hashes.
MD5 has never been there for security, it has been there for a download integrity check, not a security check. If someone wanted to maliciously alter a package, they could do it much easier than trying to find some stupid collision- they could simply make a malicious package and then insert the new MD5 in the database. I doubt SHA1 is going to make a difference there...
]]>Therefore I'd like to ask: Would it be possible to have an official dedicated server which only serves package-metainformation with SSL-authentication?
If yes, then we could have a procedure in which the client first asks the central server for the official metadata and then the client decides for itself which packages should be retrieved from a mirror.
This would make downgrades impossible and updates would only allow the current version, (If packages are signed or if there are hashes)
If implemented, the pacman-protocol needs to be extended, so that mirror-servers could respond with "package version not available yet". The error message should be shown to the user so that he/she can decide, if the mirror is current enough.
Well these sorts of things are being thought about. There is a signed packages branch of pacman being worked on. It won't make the next pacman release, but maybe the one after. I know the attack described is also applicable to signed packages but it is a start.
It's nice to hear that signed packages are beeing worked on. But for the meantime I would propose additional sha1-checksums for each package, because md5 can no longer be considered secure enough. If two different hashes are applied, it's extremely difficult for an attacker to find a collision, which matches both hashes.
]]>remote wrote:Perhaps it's my lack of knowledge then, for after fresh install and no on-line connection pacman -S iptables fails. What method do I use?
Add the iso as a pacman repo, or use -U /path/to/pkg
Or select it during the install process.. It's there. Has been for a while.
]]>Perhaps it's my lack of knowledge then, for after fresh install and no on-line connection pacman -S iptables fails. What method do I use?
Add the iso as a pacman repo, or use -U /path/to/pkg
]]>If looking for votes, it has mine. I'd also like to have iptables included in the base/core install so that I can add security before going on-line.
Around here we rarely look for votes, but patches and code are more than welcome. Until we have more than 4 active developers on pacman, we just don't have the manpower to care about these issues (as important as some of this stuff may be). We have had stops and starts of work on some signed package stuff, and I haven't read the whole article yet but I'm sure we will have other work to do too. It just comes down to someone *doing* rather than talking about it and expecting the work to magically happen.
]]>