Am 14.02.2012 23:08, schrieb Dave Reisner:
On Tue, Feb 14, 2012 at 02:30:06PM -0600, Dan McGee wrote:
This has outlived its usefulness and causes more problems than it solves.
Signed-off-by: Dan McGee <dan@archlinux.org> ---
This is an RFC first of all, so please feel free to comment.
Pros: 1. Removes complexity and a fair amount of code. 2. Removes the hack necesary for download-only and print operations. 3. Closes at least two bug reports. 4. Pacman is now much more resiliant to updates to itself since vercmp is statically linked, etc. so updating it alone isn't always necessary.
Cons: 1. If a major underlying change occurs (such as a new compression format), users would need to update pacman explicitly first. 2. ???
Just to be a jerk... Suppose the following:
- The fabled keyring package exists. Life is awesome. - I go insane and have to be forcefully removed from the dev team, and my packaging key needs to be blacklisted. Alternatively, I'm off on vacation and my desktop+gpg key is compromised. Same end effect. - It's assumed that a number of the packages that I maintain are now highly suspect and should NOT be installed.
In this case, SyncFirst seems like the only way to make sure that people are safe from the rootkits that are infecting my packages.
SyncFirst wont help if I am able to sign malicious packages: I'll just sign my own keyring package. I don't think there is any automatic method to guarantee a secure update once a signing keys has been compromised. (This is also why https and OCSP just cannot work; esp. when the attacker owns the network) Anyway: I think it'll be a good idea to remove the SyncFirst feature as it indeed introduces some strange side effects. For some of them we abused some versioned deps from the pacman package. But one result is that your system might be in an inconsistent stage after the SyncFirst run. I don't think we need to be afraid about having the user to perform some potential manual steps on major updates. Greetings, Pierre -- Pierre Schmitz, http://pierre-schmitz.com