On Wed, Feb 15, 2012 at 07:34:54AM +0100, Pierre Schmitz wrote:
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)
No, there isn't. Another problem is that there will always be some kind of delay before we notice that a key is compromised. Anyone doing a system update during this delay time will possibly be affected by malicious packages. I think that Dave is/was talking about reducing the delay by enforcing a new keyring package after we removed the malicious user from our "authorized_keys", though. If there's no way to enforce and prioritize such an package, all systems continue to be affected until we finished following steps: * Revoke that developer's/TU's SSH access. * Push a new keyring package (any systems that didn't pull in malicious packages yet would be safe from now on if we "SyncFirst" the keyring package). * Add a big warning to our front page. * Review all recent commits of that user in detail (and/or revert all or some of them, depending on how consistent and systematical we want to be). * Rebuild all packages signed with the compromised key. * Add another big warning to our front page recommending everyone, who updated their system recently, to reinstall everything and restore data from an older backup. There might be other solutions than "SyncFirst" but it's a good idea to discuss this before it is "too late"...
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