[pacman-dev] [PATCH] Remove SyncFirst option

[Lukas Fleischer]

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 at 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