FS#11573 - Optional load repo database from other server
Attached to Project:
Pacman
Opened by Gerhard Brauer (GerBra) - Wednesday, 24 September 2008, 09:50 GMT
Last edited by Xavier (shining) - Wednesday, 24 September 2008, 13:31 GMT
Opened by Gerhard Brauer (GerBra) - Wednesday, 24 September 2008, 09:50 GMT
Last edited by Xavier (shining) - Wednesday, 24 September 2008, 13:31 GMT
|
Details
I would like to have an Option (general or per repo) to
choose from which server i download the current
$repo.db.tar.gz during an -Sy.
The md5sum check is our only integrity check on a package. So if we could choose a trusted source location for the database it was more difficult to manipulate packages on an hacked or malicious mirror. The implementation could be: * Without a setting all db files are downloaded from ftp.archlinux.org * User could set an other generally location in pacman.conf * User could set it per repo in pacman.conf I could not provide a patch (no C experience) but i think this could be easilier implemented as package signing, and could be a first step of pacman security framework. |
This task depends upon
Closed by Xavier (shining)
Wednesday, 24 September 2008, 13:31 GMT
Reason for closing: Won't implement
Additional comments about closing: see comments
Wednesday, 24 September 2008, 13:31 GMT
Reason for closing: Won't implement
Additional comments about closing: see comments
FS#5331is the only viable way to solve the problem; this sounds like just another workaround.1) ftp.archlinux.org is just another mirror anyway, so could be easily hacked.
2) Even if done, this would need to be done in some distro-agnostic way.
3) md5sums are in no way a security feature. They are *only* for a quick check that the download was successful.
It is also important to consider that work on package signing has already started :
http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=shortlog;h=refs/heads/gpg
We just need people interested to finish this work.
To you both: ok, better let manpower go to work on signing packages instead of workarounds.
So you could close this feature resquest.
I will close now.